Stable GnuPG interface, git should use GPGME
bernhard at intevation.de
Mon Mar 13 11:30:27 CET 2017
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
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
dpkg -s gnupg2 | grep ^Version
* Use a different config for gpg2 and gpg, e.g. ~/.gnupg/gpg.conf-2
* 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
(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
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.
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...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel