Am Freitag 10 März 2017 19:54:19 schrieb Linus Torvalds: > On Fri, Mar 10, 2017 at 2: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. > > Quite frankly, I will NAK this just based on previous bad experiences > with using "helpful" libraries. > > Maybe you can lay my worries to rest, but the problems with libraries > in this context tend to be As gpgme is not just a helpful library, but the official API to GnuPG, it is well supported by the GnuPG-Initiative itself and stable. Still there could be problems and of course in some situations the disadvantages outweigh the advantages. On the other hand we have seen a number of systematic problems with "just calling gpg" that libgpgme tries to provide a solution to. So it is too early to say that libgpgme would be right choice for git to me, but it should be seriously considered. Grateful that you have written down some of your concern, let me try give you some pointers. > - hard to personalize. > > At least right now, we just allow people to set their gpg binary. > I'm betting that the library would pick whatever random preferred > version, and in the process possibly screwed us. > > Example: what if somebody is actually using another pgp > implementation entirely for some reason, and is just scripting around > it? > Or maybe he's using the regular gnupg, but using different keys for > different projects (using "--homedir"). That's trivial with the > current model. How trivial is that with a library? https://www.gnupg.org/documentation/manuals/gpgme/Engine-Configuration.html " You can change the configuration of a backend engine, and thus change the executable program and configuration directory to be used. You can make these changes the default or set them for some contexts individually. " Using a completely different OpenPGP implementation maybe a potential use case for keeping a configuration option around. I did not deeply examine what git really needs. Usually a different implementation will have quite a different command line interface, so it may require substaintial work to come up with a wrapper about that other OpenPGP implementation to provide the same command line interface as GnuPG. > - existing configuration > > This is the main problem I've seen in the past. Using the "ssh" > _program_ is easy. You add your keys, your config files, whatever, and > it "just works" (or rather, you fight it once and it definitely > doesn't "just" work, but then you copy your .ssh directory around for > the rest of your and forget how it ever worked, but it does). gpgme via gpg uses the existing configuration files (which you can also read and modify with gpgconf for implementiong GUIs). > - UI > > For things like gpg, the UI is traditionally horrible. But there > tends to be various things like password agents that help with caching > passwords and/or add a graphical UI to get the password when > necessary. As the gpg binary itself speaks to gpg-agent, this is fully integrated when used via gpgme. Our GPA and Kleopatra GUIs work fine with gpgme and others as well, because they call come together in the deeper engine functions of GnuPG. > - library versioning. > > I don't know why, but I've never *ever* met a library developer who > realized that libraries were all about stable API's, and the library > users don't want to fight different versions. In my experience Werner (the lead GnuPG developers) is quite reasonable about keeping APIs stable (he often goes out of his way to keep even the command line version stable, maybe he shouldn't do that to the command line options so you are more motivated to go to this official API gpgme. >:) ) > And to make matters worse, the different versions (particularly if > you end up having to use a development version due to bugs or required > features etc) are always made horribly bad to even detect at > built-time automatically with simple #ifdef etc, so now you have to do > autoconf crap etc. https://www.gnupg.org/documentation/manuals/gpgme/Library-Version-Check.html " The function gpgme_check_version has four purposes. It can be used to retrieve the version number of the library. In addition it can verify that the version number is higher than a certain required version number. In either case, the function initializes some sub-systems, and for this reason alone it must be invoked early in your program, before you make use of the other functions in GPGME. The last purpose is to run selftests. As a side effect for W32 based systems, the socket layer will get initialized. " > Now, it may be that the pgpme library "just works" across > architectures and handles all of the above situations as gracefully as > the external program does. In that case - but _ONLY_ in that case - > would a switch-over to the library possibly be a good thing. At least gpgme aims to fulfill these goals (and is used on many architectures). > I'd be pleasantly surprised. But I *would* be surprised, because every > time I've seen that "library vs program" model, I've seen the above > issues. Your concerns are understandable, I've seen similiar problems with "library vs program" and the unix tools box approach gives a number of lessons on how to losely couple components. Thanks again for taking the time and writing them down. I've given you some pointers why gpgme indeed could be different and may be an improvement for git (or other applications). I guess one of the next steps would be for someone to look for specific points or try gpgme for git purposes. Me and gnupg-devel@ are happy to take your questions or get feedback. 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.
