On Fri, Mar 10, 2017 at 11:00:07AM +0100, Bernhard E. Reiter wrote:
> My use case today was signing and git by default found the `gpg` binary by
> default and the command failed. The reason is that I have `gpg2` installed
> and most applications use it right away. So git failed signing because
> the .gnupg configuration of the user was not ready for the old `gpg` which is
> still installed on Debian GNU/Linux for purposes of the operating system. If
> git would have used libgpgme, gpgme would have choosen the most uptodate
> version of `gpg` available (or configured) without me intervening via
> gpg.program. Now because of this problem you could adding a check for `gpg2`
> and fallback to `gpg`, 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.

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.

This is not an idle consideration; we have automated systems at work
that update software automatically and submit it for human review,
including verifying signatures and hashes.  This saves hundreds of hours
of staff time and results in better security.

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.

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.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204