From: Bernhard Reiter <bernhard@intevation.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
gnupg-devel@gnupg.org,
Lukas Puehringer <luk.puehringer@gmail.com>,
Michael J Gruber <git@drmicha.warpmail.net>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Stable GnuPG interface, git should use GPGME
Date: Mon, 13 Mar 2017 11:30:27 +0100 [thread overview]
Message-ID: <201703131130.31623.bernhard@intevation.de> (raw)
In-Reply-To: <CACBZZX4Av-D6hxE9ceDFPuG-_qUQbH_6KW5JKsJf0SuH62jkuQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3870 bytes --]
Am Freitag 10 März 2017 15:23:27 schrieb Ævar Arnfjörð Bjarmason:
> On Fri, Mar 10, 2017 at 11:00 AM, Bernhard E. Reiter wrote
> > 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.
> > == Usability problem with `gpg2` vs `gpg`
> >
> > My use case today was signing and git by default found the `gpg` binary
> > by default and the command failed.
I've mentioned this as one example for a possible advantage using libgpgme
when interfacing with GnuPG.
> > 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. >:)
>
> I'm on Debian but haven't had these issues. What's your gpg & gpg2
> --version & Debian release? And what in particular failed?
If you use options in your configuration that only gpg2 understands, gpg(1)
will barf. For example the following lines in ~/.gnupg/gpg.conf
debug-level basic
log-file socket:///home/bern/.gnupg/log-socket
will lead to
LANG=C gpg -K
gpg: /powerhome/bern/.gnupg/gpg.conf:102: argument not expected
gpg: /powerhome/bern/.gnupg/gpg.conf:103: invalid option
where gpg2 works as expected.
As a number of application already uses gpg2 (via libgpgme or not), this may
go unnoticed for a while. So when I've started to sign with git on this
machine I ran into the problem (current Jessie default versions):
dpkg -s gnupg | grep ^Version
#Version: 1.4.18-7+deb8u3
dpkg -s gnupg2 | grep ^Version
#Version: 2.0.26-6+deb8u1
Workarounds are:
* Use a different config for gpg2 and gpg, e.g. ~/.gnupg/gpg.conf-2
(https://www.gnupg.org/documentation/manuals/gnupg-2.0/Invoking-GPG.html )
* or set gpg.program for git to gpg2.
> And what git version was this? I see we've had a couple of workarounds
> for gpg2, in particular Linus's v2.8.4-1-gb624a3e67f, but if you have
> v2.10.0 or later that won't fix whatever issue you had.
dpkg -s git | grep ^Version
Version: 1:2.1.4-2.1+deb8u2
(I've checked the most current master source to see that git still calls
gpg.program, otherwise followed advise on https://git-scm.com/community
to send reports and questions to the list.)
> Using the library sounds good, but a shorter-term immediate fix would
> be to figure out what bug you encountered in our use of the
> command-line version, and see if we've fixed that already or not.
> Regardless of what we do with a gpg library in the future some distros
> might want to backport such a small patch if we can come up with it.
I guess a good simple approach would be to try "gpg2" first and then fall back
to "gpg" or "gpgv" in case only these version are available.
(Here is a report that puts forward using gpgv in some situations
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852684 )
As there are other subtle potential issues with directly calling a gpg binary,
using libgpgme by default probably has other advantages as well. And if there
are important functions missing the GnuPG-devs would like to hear about them.
Regards,
Bernhard
--
www.intevation.de/~bernhard +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2017-03-13 10:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-10 10:00 Stable GnuPG interface, git should use GPGME Bernhard E. Reiter
2017-03-10 14:23 ` Ævar Arnfjörð Bjarmason
2017-03-13 10:14 ` Michael J Gruber
2017-03-13 12:49 ` Bernhard E. Reiter
2017-03-14 10:39 ` Michael J Gruber
2017-03-17 9:56 ` Bernhard E. Reiter
2017-03-22 17:15 ` Werner Koch
2017-03-22 18:46 ` Peter Lebbing
2017-03-23 6:52 ` Werner Koch
2017-03-23 7:29 ` Bernhard E. Reiter
2017-03-23 10:56 ` Werner Koch
2017-03-13 10:30 ` Bernhard Reiter [this message]
2017-03-10 18:54 ` Linus Torvalds
2017-03-10 20:26 ` Theodore Ts'o
2017-03-13 11:14 ` Bernhard E. Reiter
2017-03-13 12:53 ` Jeff King
2017-03-11 0:10 ` brian m. carlson
2017-03-13 12:29 ` Bernhard E. Reiter
2017-03-13 19:48 ` Christian Neukirchen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201703131130.31623.bernhard@intevation.de \
--to=bernhard@intevation.de \
--cc=avarab@gmail.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gnupg-devel@gnupg.org \
--cc=luk.puehringer@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).