Bernhard E. Reiter venit, vidit, dixit 13.03.2017 13:49: > 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. No, not at all. On the contrary: Using gpg2.1 without being asked to by the user will migrate his key store! This can lead to tremendous problems when a user manages his secret key store using gpg and git uses the other secret key store (via gpg2.1)! >> 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. I have no idea what you're implying here - but I have a pretty good idea of what works in current git and what not, including gpg usage (which is the qualifier that you cut out). >> 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. Unfortunately, gpgme does not solve the interoperability problems between gpg (1, classic, stable maint mode) or gpg2.0 (stable) and gpg2.1 (modern) key stores, and gpg2.2 (modern, stable) is not released yet. >> 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 Again, have you checked what we are doing in git land? Your agenda is pretty clear. It's also pretty clear from the above that gpgme is not the solution to the problem which is introduced by the migration path to versions of gpg which are not declared stable by the gpg project, away from a gpg version which is not obsoleted by the gpg project (2.0, maybe 1). And, really, key store migration was the only "major" thing we had to think about to cope with gpg 2.1+ - it affected the test suite setup. So, once 2.2 is out and stable and mainstream and we don't risk migrating users' secret key store sneakily I'm all for defaulting to gpg2, and then is a good time for us to look into gpgme. Michael