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