|
|
|
|
|
|
|
|
|
|
|
|
| Re: Latest EGit fails to sign commits with GPG [Windows] [message #1810473 is a reply to message #1810470] |
Mon, 12 August 2019 10:15   |
Eclipse User |
|
|
|
Hmm, alright.
This is the version of GPG I use. $ gpg --version
gpg (GnuPG) 2.2.16-unknown
libgcrypt 1.8.4
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /c/Users/Besitzer/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
For me it's btw no Windows issue. I tried it with a native Debian 9 installation and Eclipse, same issue.
As we see that this seems to be a problem of the BouncyCastle Lib I might also ask them about it - in case you don't see a problem with my GPG version.
|
|
|
| Re: Latest EGit fails to sign commits with GPG [Windows] [message #1810509 is a reply to message #1810473] |
Mon, 12 August 2019 17:38 |
| Eclipse User |
|
|
|
I just tried this code on a key on my machine. (Mac OS X 10.14.4, gpg (GnuPG/MacGPG2) 2.2.10). First fixed the fingerprint output, should be
System.out.println("Found key " + Hex.toHexString(key.getPublicKey().getFingerprint());
First observation: the little program can load the key on my machine.
Second observation: the fingerprint written is nonsense.
The program cannot be used to verify fingerprints. There are two variants of parseSecretKey(), and the one used in this little LoadKey program will produce a public key part with a new timestamp and thus its fingerprint won't match what gpg shows. But that's unrelated to the problem, and JGit uses the other version of parseSecretKey(), so the fingerprints in JGit would be correct if it could read your key at all.
One possibility I see is that your key is encrypted with an algorithm that Bouncy Castle doesn't know. In fact, looking at the code of SExprParser and JcePBEProtectionRemoverFactory I see it implements only AES-CBC w/SHA1. However modern GPG supports a number of other encryption schemes; see the documentation in file keyformat.txt. You can find out easily if that's the problem: open the key file FA78FB5C8C6B1B0D4CC992B62BE89C8D07DF94C8.key in a hex editor (or use xxd on Unix) and look for the string "(9:protected". If it continues with "25:openpgp-s2k3-sha1-aes-cbc((4:sha1", then it's the algorithm Bouncy Castle knows. Any other string indicates an algorithm that Bouncy Castle doesn't know about. It would decrypt the key wrongly and then fail parsing what it has wrongly decrypted.
If that's the problem, the only way to fix it is to implement these algorithms in Bouncy Castle, i.e., open a bug report against BC.
Note: if the encryption of your key is "openpgp-s2k3-ocb-aes", then please note that OCB is a patented algorithm. It must not be used in Eclipse and is excluded from the Bouncy Castle JARs included in Eclipse. In that case the only solution is to re-encrypt your key using AES/CBC, and to configure your GPG not to use that non-free AES/OCB encryption.
(And all that still doesn't explain why it sometimes worked all the same.)
[Updated on: Tue, 13 August 2019 02:10] by Moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Home