Re: Stable GnuPG interface, git should use GPGME

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

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

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

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