All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Christian Hesse <mail@eworm.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 1/1] create gpg homedir on the fly and skip RFC1991 tests for gnupg 2.1
Date: Thu, 11 Dec 2014 14:41:31 -0800	[thread overview]
Message-ID: <xmqqr3w5dd2c.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1418303772-7909-1-git-send-email-mail@eworm.de> (Christian Hesse's message of "Thu, 11 Dec 2014 14:16:12 +0100")

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.

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

>  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 ;-)

> 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.

Thanks.

  reply	other threads:[~2014-12-11 22:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-11 13:16 [PATCH v2 1/1] create gpg homedir on the fly and skip RFC1991 tests for gnupg 2.1 Christian Hesse
2014-12-11 22:41 ` Junio C Hamano [this message]
2014-12-12  8:47   ` Christian Hesse
2014-12-12  8:50     ` [PATCH 1/3] create gpg homedir on the fly Christian Hesse
2014-12-12  8:50       ` [PATCH 2/3] skip RFC1991 tests for gnupg 2.1 Christian Hesse
2014-12-12  8:50       ` [PATCH 3/3] replace binary keyrings with armored keys Christian Hesse
2014-12-12 18:36         ` Junio C Hamano
2014-12-12 20:42           ` Christian Hesse
2014-12-12 21:50             ` Junio C Hamano
2014-12-13 19:30               ` Christian Hesse
2014-12-12  8:52       ` [PATCH 1/3] create gpg homedir on the fly Eric Sunshine
2014-12-12  8:55         ` Christian Hesse
2014-12-12 18:26       ` Junio C Hamano
2014-12-12 20:33       ` Junio C Hamano
2014-12-12 20:45         ` Christian Hesse
2014-12-12 20:33       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqr3w5dd2c.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mail@eworm.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.