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
Attachment:
signature.asc
Description: This is a digitally signed message part.