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