Re: Stable GnuPG interface, git should use GPGME

From: Bernhard E. Reiter <bernhard.reiter@intevation.de>
Date: Mar 13, 2017, 12:49 UTC
Message-ID: <201703131350.00139.bernhard.reiter@intevation.de>
In-Reply-To: <a5161dd2-977b-8195-e558-01787fb3f01b@drmicha.warpmail.net>

Am Montag 13 März 2017 11:14:57 schrieb Michael J Gruber:

> Ævar Arnfjörð Bjarmason venit, vidit, dixit 10.03.2017 15:23:
> > On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter

> >> please consider using libgpgme interfacing to GnuPG, because the gpg
> >> command-line interface is not considered an official API to GnuPG by the
> >> GnuPG-devs and thus potentially unstable.

[example of gpg2 vs gpg option incompatibility cut]

> > Using the library sounds good, but a shorter-term immediate fix would
> > be to figure out what bug you encountered in our use of the
> > command-line version, and see if we've fixed that already or not.

> As far as I know, Git handles different GPG versions just fine.

As mentioned before: explicitely setting gpg.program to gpg2 helps if gpg chokes on the new config. Trying the `gpg2` binary first can be a simple fix. Using libgpgme potentially solves this and other compatility options.

Show 8 quoted lines

> The problem is the "difficult" upgrade path and mixed installations with
> gpg and gpg2.1+ that some distributions force upon you:
>
> As soon as you start gpg2.1, your (secret) key store is migrated to a
> new format without technically invalidating it. Similarly, users may
> enter gpg2.1+-only comand in the config that is actually shared with
> gpg, throwing off any use of gpg - not just by git, but also by anything
> that your distro requires gpg for (such as packaging tools and the like).

Yes, this is another example why trying `gpg2? first by default or using libgpgme keeps trouble away from users.

> In short: Users will run into problems anyway; git provides the quick
> way out (git config gpg.program gpg2), users won't be as lucky with
> other things that require gpg.

Application using libgpgme will behave fine and many user facing components use it already.

> As for the library: While - technically speaking - the command line is
> not a stable API for gpg, it does work across versions of gpg, and gpg

... to some extend.

> 2.2 will be the first real stable branch that uses the new key store
> layout. So I'd rather wait for that to stabilize before going away from
> what turned out to be most stable so far.

It is not just about the key-store change as mentioned before. However I agree that a potential switch should be done with a current version of gpgme that already has support for GnuPG 2.1/2, e.g. gpgme v1.8.0.

> Note that we (git) refrain from parsing ordinary output/return codes of
> gpg and use status-fd as we should (and as documented).

It is good to use --status-fd and --with-colons when calling gpg, you still have to parse the results of status-fd as described in doc/DETAILs. https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;hb=HEAD

Regards, Bernhard

-- 
www.intevation.de/~bernhard (CEO)     +49 541 33 508 3-3
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner