From: "Bernhard E. Reiter" <bernhard.reiter@intevation.de>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>,
gnupg-devel@gnupg.org,
"Lukas Puehringer" <luk.puehringer@gmail.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: Stable GnuPG interface, git should use GPGME
Date: Mon, 13 Mar 2017 13:49:47 +0100 [thread overview]
Message-ID: <201703131350.00139.bernhard.reiter@intevation.de> (raw)
In-Reply-To: <a5161dd2-977b-8195-e558-01787fb3f01b@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 3047 bytes --]
Am Montag 13 März 2017 11:14:57 schrieb Michael J Gruber:
> Ævar Arnfjörð Bjarmason venit, vidit, dixit 10.03.2017 15:23:
> > On Fri, Mar 10, 2017 at 11: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.
[example of gpg2 vs gpg option incompatibility cut]
> > 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.
> As far as I know, Git handles different GPG versions just fine.
As mentioned before: explicitely setting gpg.program to gpg2 helps if gpg
chokes on the new config. Trying the `gpg2` binary first can be a simple fix.
Using libgpgme potentially solves this and other compatility options.
> The problem is the "difficult" upgrade path and mixed installations with
> gpg and gpg2.1+ that some distributions force upon you:
>
> As soon as you start gpg2.1, your (secret) key store is migrated to a
> new format without technically invalidating it. Similarly, users may
> enter gpg2.1+-only comand in the config that is actually shared with
> gpg, throwing off any use of gpg - not just by git, but also by anything
> that your distro requires gpg for (such as packaging tools and the like).
Yes, this is another example why trying `gpg2? first by default or using
libgpgme keeps trouble away from users.
> In short: Users will run into problems anyway; git provides the quick
> way out (git config gpg.program gpg2), users won't be as lucky with
> other things that require gpg.
Application using libgpgme will behave fine and many user facing components
use it already.
> As for the library: While - technically speaking - the command line is
> not a stable API for gpg, it does work across versions of gpg, and gpg
... to some extend.
> 2.2 will be the first real stable branch that uses the new key store
> layout. So I'd rather wait for that to stabilize before going away from
> what turned out to be most stable so far.
It is not just about the key-store change as mentioned before. However
I agree that a potential switch should be done with a current version of gpgme
that already has support for GnuPG 2.1/2, e.g. gpgme v1.8.0.
> Note that we (git) refrain from parsing ordinary output/return codes of
> gpg and use status-fd as we should (and as documented).
It is good to use --status-fd and --with-colons when calling gpg, you still
have to parse the results of status-fd as described in doc/DETAILs.
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;hb=HEAD
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 --]
next prev parent reply other threads:[~2017-03-13 12:50 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 [this message]
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
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=201703131350.00139.bernhard.reiter@intevation.de \
--to=bernhard.reiter@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).