Ævar Arnfjörð Bjarmason venit, vidit, dixit 10.03.2017 15:23: > On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter > <bernhard.reiter@xxxxxxxxxxxxx> wrote: >> Dear Git-Devs, > > I haven't contributed to Git's GPG code, but I'm taking the liberty of > CC-ing some people who have. > >> git uses an pipe-and-exec approach to running a GnuPG binary >> as writen in the documentation [1]: >> >> gpg.program >> Use this custom program instead of "gpg" found on $PATH when making >> or verifying a PGP signature. The program must support the same >> command-line interface as GPG >> >> 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. >> >> == Details >> >> I'm involved in GnuPG development. For most applications using libgpgme is the >> way what GnuPG-devs would recommend, also see >> >> https://wiki.gnupg.org/APIs . >> >> GnuPG devs are making a good effort of trying to keep the command-line >> interface stable, though it is not for sure. Git is only using a small part >> of the interface, so the risk when keeping the current way is small. >> Still I believe git's stability and usability would profit when moving to >> libgpgme, especially with the coming move to GnuPG 2.2, better diagnosing >> messages and for cross-plattform usage. >> >> == 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. 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? > > 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. > > 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. As far as I know, Git handles different GPG versions just fine. 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). 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. 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 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. Note that we (git) refrain from parsing ordinary output/return codes of gpg and use status-fd as we should (and as documented). Michael