Fix private decoding bug

[BlackHoleFox]

Fixes a bug where the decode implementation of PrivateKey would attempt to validate the full key matched itself even when it was encrypted. This is obviously wrong so don't do that. Regression test included that fails when the fix is removed.

Depends on #60
Bug originally reported in #59 (comment)

[sug0]

I tested these changes, and unfortunately decoding encrypted keys is still broken :(
EDIT: well I guess you didn't port every change from the other pr haha

[sug0]

good call! GHSA-w5vr-6qhr-36cc

[BlackHoleFox]

I tested these changes, and unfortunately decoding encrypted keys is still broken :(

I don't quite know how to reproduce your issue yet, so no deep dive has been attempted. Is therea way you could create an encrypted key that reproduces the issue which can be uploaded here for testing?

EDIT: well I guess you didn't port every change from the other pr haha

@sug0 Apologies if that wasn't clear. I had posted on a specific thread in your PR as a scope attempt.

[sug0]

@BlackHoleFox of course. clone https://github.com/sug0/git-signify and checkout the branch signify-decoding-bug. build the bin (or run cargo run -- ...args). under the keys/ directory you'll find some sample keys I've generated with the signify cli util from openbsd; the password to the private key is 1234.

this util signs arbitrary git objects. let's say we want to sign HEAD. we can run:

cargo run -- sign -k keys/key.sec HEAD

even after you input the right password, you'll never be able to decrypt the private key. if you switch back to main, and rebuild the util, you'll be able to decrypt the key and sign HEAD.