Re: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
"Tom G. Christensen" writes: > On 29/01/15 16:43, Jeff King wrote: > >> Another option is to just declare that version old and broken, and skip >> the tests (either by checking its version, or just checking after we >> import the keys that we can actually _use_ them). >> > That would seem a bit heavy-handed as it is otherwise working fine > with the old gnupg. Thanks, both, for tracking this one down. I am tempted to say that we should do both. This "export public key, even though new importers do not need" fix to make things usable with 1.2.6, and the other one to catch and skip breakages when future versions of GPG breaks us in whichever way we do not anticipate now. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On 29/01/15 16:43, Jeff King wrote: Weird. The pubkeys are there in keyring.gpg; I wonder why the older version of gpg has trouble extracting them (and how one was _supposed_ to export secret keys at that time). Importing the unmodified keyring.gpg with 1.2.6 yields this: $ gpg --homedir "$GNUPGHOME" --import /tmp/keyring.gpg gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: key B7227189: secret key imported gpg: Total number processed: 2 gpg: secret keys read: 2 gpg: secret keys imported: 2 $ gpg --homedir "$GNUPGHOME" --list-keys $ gpg --homedir "$GNUPGHOME" --list-secret-keys /home/tgc/gpghome/secring.gpg - sec 1024D/CDDE430D 2007-06-07 C O Mitter ssb 2048g/7703B0E5 2007-06-07 sec 2048R/B7227189 2013-03-22 Eris Discordia ssb 2048R/29472784 2013-03-22 $ So if I understand you correctly, the tests should pass with the patch below? Yes, adding the pubkeys as a separate entity makes gpg 1.2.6 understand things fine. gnupg 1.2.6 with the patched keyring: $ gpg --homedir "$GNUPGHOME" --import /tmp/keyring.gpg gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: key B7227189: secret key imported gpg: /home/tgc/gpghome/trustdb.gpg: trustdb created gpg: key CDDE430D: public key "C O Mitter " imported gpg: key B7227189: public key "Eris Discordia " imported gpg: Total number processed: 4 gpg: imported: 2 (RSA: 1) gpg: secret keys read: 2 gpg: secret keys imported: 2 $ gpg --homedir "$GNUPGHOME" --list-keys /home/tgc/gpghome/pubring.gpg - pub 1024D/CDDE430D 2007-06-07 C O Mitter sub 2048g/7703B0E5 2007-06-07 pub 2048R/B7227189 2013-03-22 Eris Discordia sub 2048R/29472784 2013-03-22 $ The patch should work as posted, though I have only tested the new keyring by hand as shown above. It feels a bit hacky, and I wish I knew more about why the current file doesn't work (i.e., if we did "gpg --export-secret-keys" with v1.2.6, would it produce different output that can be read by both versions?). I grabbed the binary keyrings from 1e3eefb^ and pointed gpg 1.2.6 at them. $ gpg --homedir "$GNUPGHOME" --armor --export-secret-keys CDDE430D > CDDE430D.secret.key $ gpg --homedir "$PWD/gpghome3" --import CDDE430D.secret.key gpg: keyring `/home/tgc/gpghome3/secring.gpg' created gpg: keyring `/home/tgc/gpghome3/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: Total number processed: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg --homedir "$PWD/gpghome3" --list-keys $ No public key imported however the pubkey *was* exported to CDDE430D.secret.key Importing that same keyfile using gnupg 1.4.5 on an RHEL5 host: $ gpg --homedir "$PWD/gpghome" --import /tmp/CDDE430D.secret.key gpg: keyring `/home/tgc/gpghome/secring.gpg' created gpg: keyring `/home/tgc/gpghome/pubring.gpg' created gpg: key CDDE430D: secret key imported gpg: /home/tgc/gpghome/trustdb.gpg: trustdb created gpg: key CDDE430D: public key "C O Mitter " imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg --homedir "/home/tgc/gpghome" --list-keys /home/tgc/gpghome/pubring.gpg - pub 1024D/CDDE430D 2007-06-07 uid C O Mitter sub 2048g/7703B0E5 2007-06-07 $ So gnupg 1.2.6 can export fine but cannot correctly import the same. Another option is to just declare that version old and broken, and skip the tests (either by checking its version, or just checking after we import the keys that we can actually _use_ them). That would seem a bit heavy-handed as it is otherwise working fine with the old gnupg. -tgc -- Tom G. Christensen - Systemmedarbejder - IT-drift Statsbiblioteket - Victor Albecks Vej 1 - 8000 Aarhus C Tlf: (+45) 8946 2027 - Fax: (+45) 8946 2029 CVR/SE: 10100682 - EAN: 5798000791084 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On Thu, Jan 29, 2015 at 10:43:20AM -0500, Jeff King wrote:
> It feels a bit hacky, and I wish I knew more about why the current file
> doesn't work (i.e., if we did "gpg --export-secret-keys" with v1.2.6,
> would it produce different output that can be read by both versions?).
> Another option is to just declare that version old and broken, and skip
> the tests (either by checking its version, or just checking after we
> import the keys that we can actually _use_ them).
That would look like this:
-- >8 --
Subject: [PATCH] t/lib-gpg: sanity-check that we can actually sign
Some older versions of gpg (reportedly v1.2.6 from RHEL4)
cannot import the keyrings found in our test suite, and thus
cannot even make a signature. We can detect this case by
doing a test-sign before declaring the GPG prerequisite
fulfilled.
Signed-off-by: Jeff King
---
t/lib-gpg.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
index d88da29..a87747a 100755
--- a/t/lib-gpg.sh
+++ b/t/lib-gpg.sh
@@ -34,6 +34,8 @@ else
"$TEST_DIRECTORY"/lib-gpg/keyring.gpg &&
gpg --homedir "${GNUPGHOME}" 2>/dev/null --import-ownertrust \
"$TEST_DIRECTORY"/lib-gpg/ownertrust &&
+ gpg --homedir "${GNUPGHOME}" /dev/null 2>&1 \
+ --sign -u commit...@example.com &&
test_set_prereq GPG
;;
esac
--
2.3.0.rc1.287.g761fd19
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]
On Thu, Jan 29, 2015 at 02:11:05PM +0100, Tom G. Christensen wrote: > All signed commit tests fail on RHEL4 which is a regression from 2.2.2. > > From t4202.42: > > ++ git tag -s -m signed_tag_msg signed_tag > gpg: key CDDE430D: secret key without public key - skipped > gpg: skipped `C O Mitter ': secret key not available > gpg: signing failed: secret key not available > error: gpg failed to sign the data > error: unable to sign the tag > error: last command exited with $?=128 > > There are indeed no public keys available after commit 1e3eef which seems to > be contrary to the commit log: > >Instead import public and secret keys for one key pair from a text >file that holds ASCII-armored export of them. > > > I extracted the pubkeys as ascii armored text from the old binary keyrings > and added them to the new keyring.gpg and then the tests pass. > > This is apparently only a problem for older gnupg versions (RHEL4 has gnupg > 1.2.6) since it did not fail on RHEL5 (gnupg 1.4.5). Weird. The pubkeys are there in keyring.gpg; I wonder why the older version of gpg has trouble extracting them (and how one was _supposed_ to export secret keys at that time). So if I understand you correctly, the tests should pass with the patch below? It feels a bit hacky, and I wish I knew more about why the current file doesn't work (i.e., if we did "gpg --export-secret-keys" with v1.2.6, would it produce different output that can be read by both versions?). Another option is to just declare that version old and broken, and skip the tests (either by checking its version, or just checking after we import the keys that we can actually _use_ them). -- >8 -- Subject: [PATCH] t/lib-gpg: include separate public keys in keyring.gpg Since 1e3eefb (tests: replace binary GPG keyrings with ASCII-armored keys, 2014-12-12), we import our test GPG keys from a single file. Each keypair in the import stream contains both the secret and public keys. However, older versions of gpg reportedly fail to import the public half of the key. We can solve this by including duplicates of the public keys separately. The duplicates are ignored by modern gpg, and this makes older versions work. Reported by Tom G. Christensen on gpg 1.2.6 (from RHEL4). Signed-off-by: Jeff King --- t/lib-gpg.sh | 2 ++ t/lib-gpg/keyring.gpg | 54 +++ 2 files changed, 56 insertions(+) diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh index d88da29..16e0d3f 100755 --- a/t/lib-gpg.sh +++ b/t/lib-gpg.sh @@ -23,6 +23,8 @@ else # To write armored exported key to keyring: # gpg --homedir /tmp/gpghome --export-secret-keys \ # --armor 0xDEADBEEF >> lib-gpg/keyring.gpg + # gpg --homedir /tmp/gpghome --export \ + # --armor 0xDEADBEEF >> lib-gpg/keyring.gpg # To export ownertrust: # gpg --homedir /tmp/gpghome --export-ownertrust \ # > lib-gpg/ownertrust diff --git a/t/lib-gpg/keyring.gpg b/t/lib-gpg/keyring.gpg index fb1f048..d4754a1 100644 --- a/t/lib-gpg/keyring.gpg +++ b/t/lib-gpg/keyring.gpg @@ -86,3 +86,57 @@ Z9Ei+zj6JD5Pcdi3BJhQo9WOLOVEJ0NHmewTYqk9QVXH/0v1Hdl4LMJtgcbdbDWk BOW78WUxzhu0YJTLKy+iKCjg5HS5dx6OC+e4aEEgfhNPCMkbvDsJjtQ= =hieJ -END PGP PRIVATE KEY BLOCK- +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1 + +mQGiBEZnyykRBACzCPjIpTYNL7Y2tQqlEGTTDlvZcWNLjF5f7ZzuyOqNOidLUgFD +36qch1LZLSZkShdR3Gae+bsolyjxrlFuFP0eXRPMtqK20aLw7WZvPFpEV1ThMne+ +PRJjYrvghWw3L0VVIAIZ8GXwrVBuU99uEjHEI0ojYloOvFc2jVPgSaoBvwCg48Tj +fol2foSoJa7XUu9yAL8szg8D/RUsTzNF+I9hSRHl7MYKFMYoKEY9BDgrgAujp7YY +8qdGsiUb0Ggyzp2kRjZFt4lpcvKhGfHn5GEjmtk+fRbD5qPfMqKFW+T0NPfYlYmL +JJ4fs4qZ8Lx7x6iG6X51u+YNwsQuIGjMCC3CeNi3F7or651kkNYASbaQ1NROkCIN +NudyA/0aasvoZUoNJAc2cP5Ifs6WhXMWLfMR2p2XbfKwKNYneec60usnSComcKqh +sJVk0Gytvr3FOYVhRkXnKAbx+0W2urFP8OFVBTEKO6Ts2VygWGgneQYoHnqzwlUE +yjOjlr+lyf7u2s/KAxpKA6jnttEdRZAmzWkhuox1wwAUkr27/bQiQyBPIE1pdHRl +ciA8Y29tbWl0dGVyQGV4YW1wbGUuY29tPoheBBMRAgAeBQJGZ8spAhsDBgsJCAcD +AgMVAgMDFgIBAh4BAheAAAoJEBO29R7N3kMNdB0AoL3Z/7A6tORuY8R/676oD8a/ +oHFDAJ9DXbwlcKLcykwHy0jYqajXm1iCebkCDQRGZ8tOEAgAzrl5P1Pr6CDR8mf5 +DGGzcUUM+PEroA4FLdKJ5ZaZc7qy1lmmW9vuvb6xdinwcwee2c5fdNE+iUjHV2x2 +S/dbfDzJTN/0uajZcw+xnf+KxZ0Rs4gDSs7cHXHBtA7u8ShYd4Hu7JggXpiwgfSk +yrGQiZyLAHW2ck8H07Go8eUP8fLIeva+iPqeYQZo9BaPz92R/J6debpeY1lRkv+y +WTq1GE3C/hxbdBAuHf2duLP2uq9kwoVdfzCRjgV1CQmMIbCrMb7vIlzIe96bb3+K +r/+NEtmB2I3wHBXcwJMnIOnz9Zv933KNlxSbVF23BGLB+F9D7OanKymbs7Eg18fr +mt/t/wAEDQgAtGIxGz944Pn2OtheY9JlBRuIAuVskm24/Zz03dZnk6CuEOIBb5IM +g36GAPKcn1vsLZ0TfE1q53jNpcAAXjgngnRsCjZm1mglqPD4ZfBpl+Hhnuc80fAR +xsUPj+5c8KP2M+Rws4moaZRjVpd3KCi3ceflT/OjwnE9DzdhslCGTMA5n8cajAs2 +oqAaQssefVf2prLQLGV9NB4Q3lFnKXdvipHMaAYAsW+iF7JkhTDVNuNGlufeSqUm +igRBjTZXBcVd8sj8vDOCWKUfqxJyS+zRYcotn7QvpvcKAkc3ZGxntDHAIGLVp6ay ++vrkV4Ren8BjFobl25Ruy6Abw+CgnTpuwYhJBBgRAgAJBQJGZ8tOAhsMAAoJEBO2
