Re: [PATCH v2 1/1] create gpg homedir on the fly and skip RFC1991 tests for gnupg 2.1

From: Christian Hesse <mail@eworm.de>
Date: Dec 12, 2014, 08:47 UTC
Message-ID: <20141212094753.160a0fb5@leda.localdomain>
In-Reply-To: <xmqqr3w5dd2c.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> on Thu, 2014/12/11 14:41:

Show 12 quoted lines

> Christian Hesse <mail@eworm.de> writes:
> 
> > GnuPG 2.1 homedir looks different, so just creat it on the fly by
> > importing needed private and public keys and ownertrust.
> > This solves an issue with gnupg 2.1 running interactive pinentry when
> > old secret key is present.
> >
> > Additionally GnuPG 2.1 does not longer support RFC1991, so skip these
> > tests.
> > ---
> 
> Needs a sign-off.

Damn... But yes, you are right. ;)

> Are older GPG implementations still happy with this new way to
> initialize their gpghome?

Yes, tested with gnupg 1.4.10 from Debian squeeze (6.x). Everybody is welcome to test on her/his distribution, though. ;)

Show 16 quoted lines

> >  t/lib-gpg.sh          |  13 ++++++++++---
> >  t/lib-gpg/ownertrust  |   4 ++++
> >  t/lib-gpg/random_seed | Bin 600 -> 0 bytes
> >  t/lib-gpg/trustdb.gpg | Bin 1360 -> 0 bytes
> >  t/t7004-tag.sh        |  14 +++++++-------
> >  5 files changed, 21 insertions(+), 10 deletions(-)
> >  create mode 100644 t/lib-gpg/ownertrust
> >  delete mode 100644 t/lib-gpg/random_seed
> >  delete mode 100644 t/lib-gpg/trustdb.gpg
> 
> Do these trust files need to be shipped?  In other words, would it
> be insufficient to just import private-public keyrings?  I know we
> have been shipping trustdb.gpg, and I do not think it is a problem
> to ship export-ownertrust output, but as long as we are cleaning
> things up to make us compatible with both older and newer GPG,
> I thought I'd ask ;-)

Yes, we need this. Some tests check for the trust level, e.g t7510-signed-commit.sh being one of these.

Show 39 quoted lines

> > diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
> > index cd2baef..17c45ad 100755
> > --- a/t/lib-gpg.sh
> > +++ b/t/lib-gpg.sh
> > @@ -16,12 +16,19 @@ else
> >  		# Type DSA and Elgamal, size 2048 bits, no expiration
> > date. # Name and email: C O Mitter <committer@example.com>
> >  		# No password given, to enable non-interactive operation.
> > -		cp -R "$TEST_DIRECTORY"/lib-gpg ./gpghome
> > -		chmod 0700 gpghome
> > -		chmod 0600 gpghome/*
> > +		mkdir ./gpghome
> > +		chmod 0700 ./gpghome
> >  		GNUPGHOME="$(pwd)/gpghome"
> >  		export GNUPGHOME
> > +		gpg --homedir "${GNUPGHOME}" --import \
> > +			"$TEST_DIRECTORY"/lib-gpg/pubring.gpg \
> > +			"$TEST_DIRECTORY"/lib-gpg/secring.gpg
> > +		gpg --homedir "${GNUPGHOME}" --import-ownertrust \
> > +			"$TEST_DIRECTORY"/lib-gpg/ownertrust
> >  		test_set_prereq GPG
> > +		if [ -e "${GNUPGHOME}"/pubring.kbx ]; then
> > +			test_set_prereq GNUPG21
> > +		fi
> 
> Instead of !GNUPG21 prerequisite, how about using a RFC1991
> prerequisite, which is satisfied by older GPG but not by the ones
> that lack support?  That is,
> 
> 	...
>         test_set_prereq GPG
> 	if ! test "${GNUPGHOME}"/pubring.kbx
>         then
> 		test_set_prereq GPG_RFC1991
> 	fi
> 
> or something.  That way, we do not have to be in a funny situation
> where we say a version of GPG satisfies GNUPG21 prereq but it in
> fact is GPG version 4.3 in the future.

Makes sense. In addition I do check if gpg does work if --rfc1991 is given, no more checking for keyring file.

I will reply with a new series of patches.

-- 
Best regards,
Chris