Re: Stable GnuPG interface, git should use GPGME

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

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

Am Samstag 11 März 2017 01:10:31 schrieb brian m. carlson:
> On Fri, Mar 10, 2017 at 11:00:07AM +0100, Bernhard E. Reiter wrote:
> >  but even better would be to move to libgpgme. >:)
>
> There are a couple potential problems I see with this approach.  First,
> I'd want to know whether gpgme supports gpgsm, which I know some people
> use to sign commits and tags.

Yes, gpgme supports gpgsm.
https://www.gnupg.org/documentation/manuals/gpgme/Cryptographic-Message-Syntax.html
"CMS is implemented by GpgSM, the S/MIME implementation for GnuPG."

> Another issue is what happens to the git verify-* --raw output.  Some
> people want the ability to script signature verification.  This can be
> really important when you have automated systems verifying tags and
> commits.
>
> For example, running the following commands, we can determine that Junio
> signs his tags with SHA-1 (algorithm 2), while I sign my commits with
> SHA-512 (algorithm 10).
>
> genre ok % git verify-tag --raw v2.12.0 2>&1 | grep VALIDSIG
> [GNUPG:] VALIDSIG E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB 2017-02-24
> 1487962205 0 4 0 1 2 00 96E07AF25771955980DAD10020D04E5A713660A7 genre ok %
> git verify-commit --raw object-id-part10 2>&1 | grep VALIDSIG [GNUPG:]
> VALIDSIG 5FC3A781776B26DF87F70C37BF535D811F52F68B 2017-03-06 1488760639 0 4
> 0 1 10 00 88ACE9B29196305BA9947552F1BA225C0223B187
>
> There's literally no other way to get this information at the moment
> (which is why I added the --raw option).  A gpgme implementation would
> need to expose this same information, at which point, we might as well
> have used gpg directly.

I'm quite optimistic that the use case can be covered implementing the 
git --raw option using gpgme, but I don't know the best way right away.
(I also wonder what would happen if someone manages to put in two or more 
signatures in the object you are verifying.)

> Because the amount of the gpg API we actually use is very small, a user
> who wants to use a custom signature program (say, OpenBSD's signify),
> can actually write a simple wrapper that mimics it and use that instead.

I agree that this can be a use case against using libgpgme.

> Finally, I work on a development system where work is done both as an
> unprivileged user and as root.  Because I use the same socket for both,
> GnuPG screams bloody murder that the permissions are wrong.  I know this
> is secure in my scenario, but without a custom wrapper, I have to deal
> with GnuPG polluting my terminal every time I sign a commit or a tag.  A
> gpgme implementation would need to honor the same wrapper script or
> otherwise not scream to the terminal.

I don't understand  the scenario well enought to advise. Using the same socket 
sounds strange at the onset. In general libgpgme allows someone to use other 
binaries (see my answer to Linus) and offers quite a number of possibilities. 
However there may be special cases that are not covered as good as using 
everything raw and manually. Libgpgme has to be this way and offering some 
standard default otherwise it would use some of its merits. On the other hand
the code doing special things or calling gpg directly can have defects as well
which is a significant drawback.

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