Subject: Re: All gnupg tests broken on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]

From: Jeff King <[email-masked]>
Date: Thu, 29 Jan 2015 10:43:20 -0500

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 <[email-masked]>': 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 <[email-masked]> on
gpg 1.2.6 (from RHEL4).

Signed-off-by: Jeff King <[email-masked]>
---
 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
+
+=iYv/
+-----END PGP PUBLIC KEY BLOCK-----
-- 
2.3.0.rc1.287.g761fd19