Stable GnuPG interface, git should use GPGME

[Bernhard Reiter]

Am Freitag 10 März 2017 15:23:27 schrieb Ævar Arnfjörð Bjarmason:
> On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter wrote
> > 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.

> > == Usability problem with `gpg2` vs `gpg`
> >
> > My use case today was signing and git by default found the `gpg` binary
> > by default and the command failed.

I've mentioned this as one example for a possible advantage using libgpgme
when interfacing with GnuPG.

> > The reason is that I have `gpg2` 
> > installed and most applications use it right away. So git failed signing
> > because the .gnupg configuration of the user was not ready for the old
> > `gpg` which is still installed on Debian GNU/Linux for purposes of the
> > operating system. If git would have used libgpgme, gpgme would have
> > choosen the most uptodate version of `gpg` available (or configured)
> > without me intervening via gpg.program. Now because of this problem you
> > could adding a check for `gpg2` and fallback to `gpg`, but even better
> > would be to move to libgpgme. >:)
>
> I'm on Debian but haven't had these issues. What's your gpg & gpg2
> --version & Debian release? And what in particular failed?

If you use options in your configuration that only gpg2 understands, gpg(1)
will barf. For example the following lines in ~/.gnupg/gpg.conf

  debug-level basic
  log-file socket:///home/bern/.gnupg/log-socket

will lead to
LANG=C gpg -K
  gpg: /powerhome/bern/.gnupg/gpg.conf:102: argument not expected
  gpg: /powerhome/bern/.gnupg/gpg.conf:103: invalid option
where gpg2 works as expected.

As a number of application already uses gpg2 (via libgpgme or not), this may 
go unnoticed for a while. So when I've started to sign with git on this 
machine I ran into the problem (current Jessie default versions):

  dpkg -s gnupg | grep ^Version
  #Version: 1.4.18-7+deb8u3
  dpkg -s gnupg2 | grep ^Version
  #Version: 2.0.26-6+deb8u1

Workarounds are:
 * Use a different config for gpg2 and gpg, e.g. ~/.gnupg/gpg.conf-2
   (https://www.gnupg.org/documentation/manuals/gnupg-2.0/Invoking-GPG.html )
 * or set gpg.program for git to gpg2.

> And what git version was this? I see we've had a couple of workarounds
> for gpg2, in particular Linus's v2.8.4-1-gb624a3e67f, but if you have
> v2.10.0 or later that won't fix whatever issue you had.

dpkg -s git | grep ^Version
Version: 1:2.1.4-2.1+deb8u2
(I've checked the most current master source to see that git still calls 
gpg.program, otherwise followed advise on https://git-scm.com/community
to send reports and questions to the list.)

> 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.
> Regardless of what we do with a gpg library in the future some distros
> might want to backport such a small patch if we can come up with it.

I guess a good simple approach would be to try "gpg2" first and then fall back 
to "gpg" or "gpgv" in case only these version are available.
(Here is a report that puts forward using gpgv in some situations 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852684 )

As there are other subtle potential issues with directly calling a gpg binary,
using libgpgme by default probably has other advantages as well. And if there 
are important functions missing the GnuPG-devs would like to hear about them.

Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170313/965c3077/attachment.sig>