Re: Stable GnuPG interface, git should use GPGME

["Bernhard E. Reiter" <bernhard.reiter@intevation.de>]

[-- Attachment #1: Type: text/plain, Size: 6648 bytes --]

Am Dienstag 14 März 2017 11:39:12 schrieb Michael J Gruber:
> >> 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 the following scenario I agree with you:
* The user only uses gpg (1) and only applications that use gpg (1)
   and does not have gpg2 installed.
* Now a GnuPG package for 2.1/2.2 is installed and only the "gpg2"
  binary now points to it.
* If then git will just switches using `gpg2` which is v2.1 because it 
  came available, it will force the migration to the new store.

My statement was assuming a scenario where
* the user has gpg v1 and gpg2 v2.0 installed and many (or all) applications 
  use gpg2 via gpgme or by other means. I consider this typical for desktops
  or application servers using for desktop or development work.
* Now git also uses gpg2 (via gpgme or by other means, a possible improvement 
   we are just talking about)
* If GnuPG 2.1/2.2 becomes available and of the already used application will
  trigger the keystore migration. git users will have a smooth experience
  because they were using gpg2 all along and then to use the new keystore.

(It is still possible for some to configure libgpgme to use `gpg` v1 and all 
applications using gpgme will use it and you do not have to configure each 
one separately. Because you should either use gpg v2.1 or gpg v1 
exclusively, it makes sense to configure it close to gpg in its official api 
and not within each application. Again you can deviate from this.)

> >> 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).

As the command line is not a stable API to GnuPG, there were changes and there 
will be changes to the command line over several versions. It maybe in the 
past that git's usage of the command line was stable and works well, because 
of the subset of functionality of GnuPG that git is using and good work done 
by you and other developers of the git GnuPG support. It may or may not be a 
good choice for the future. As I've written before I'm not familiar enough 
with git to make a final call here, but there are some signs and examples 
where using gpgme may be an improvements in the areas:

* better configuration which gpg and which options to use for all applications
* consistent behaviour from git with other applications
* more robust programming interface over several gpg versions
* (better performance when reusing the same gpgme "context" for many 
consecutive crypto operations)

> 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.

That is right, I also believe gpgme does not solve all interoperability 
problems. I guess it solves some, but I would do more research to come up 
with some specific examples.

> >> 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?

As mentioned before: Only on the surface. I'm not deeply familiar with all git 
use case of GnuPG. 

> Your agenda is pretty clear.

Yes, I'd like to improve the user experience of git users regarding crypto
operations done with GnuPG. There are some signs that indicate that using 
gpgme may potentially improve this user experience (as outlined).

> 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).

While I agree that gpgme does not solve all problems with this migration,
it solves some problems with it (see above and my other email) 
and offers other advantages as the official API of GnuPG. Still it is the call 
of people more familiar with git usage and use cases to see if they have a 
good reason to deviate from the common case and use a non-official way of 
automating crypto operations with GnuPG.

> 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.

The key store migration is mainly an orthogonal issue and the problems will 
happen with or without using gpgme. As GnuPG 2.2 is under way, it makes sense 
to look into an improved support now, to be ready if GnuPG 2.2 becomes more 
widely used. It probably will get a lot more usage this year because of the 
ECC support (and some other reasons).

Thanks all for your thoughts, using GnuPG, considering gpgme 
and in general for maintaining git as Free Software! :)

Best 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]