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
Attachment:
signature.asc
Description: PGP signature