From: Werner Koch <wk@gnupg.org>
To: "Bernhard E. Reiter" <bernhard.reiter@intevation.de>
Cc: "Michael J Gruber" <git@drmicha.warpmail.net>,
"Æ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: Wed, 22 Mar 2017 18:15:36 +0100 [thread overview]
Message-ID: <87poh9p70n.fsf@wheatstone.g10code.de> (raw)
In-Reply-To: <201703171056.10468.bernhard.reiter@intevation.de> (Bernhard E. Reiter's message of "Fri, 17 Mar 2017 10:56:02 +0100")
[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]
On Fri, 17 Mar 2017 10:56, bernhard.reiter@intevation.de said:
> As the command line is not a stable API to GnuPG, there were changes and there
> will be changes to the command line over several versions. It maybe in the
That is not true. The command line interface has been stable for the
last 19 years. We only removed a left over PGP-2 backward compatibility
in 2.1 (-kvv). I doubt that this has even been noticed.
>> Unfortunately, gpgme does not solve the interoperability problems
>> between gpg (1, classic, stable maint mode) or gpg2.0 (stable) and
>> gpg2.1 (modern) key stores, and gpg2.2 (modern, stable) is not released
>> yet.
It actually does. For the tasks git uses gpg you should not notice a
difference in gpgme between any of these versions. BTW, 2.1 was
realeased more than 2 years ago and 2.0 will reach EOL in 9 months.
> That is right, I also believe gpgme does not solve all interoperability
> problems. I guess it solves some, but I would do more research to come up
The main arguments pro GPGME are
- There is generic stable API and ABI which did not changes since 0.4.1
(2003-06-06) when we decided to redesign the API.
- Iff verification of signatures needs a speedup we can do this inside
GPGME and GnuPG without the GPGME user noticing that. Technically we
will then run gpg as co-process controlled by GPGME; for gpgsm
(S/MIME) this is already done but there has not yet been a need to do
this also for gpg. Git could be the trigger to implement that.
- The GPGME API would allow to provide a rich and stable output with
the pretty print format. AFAICS the current %G* format characters
are a bit limited and require that scripts need to look at the key
for further information.
> The key store migration is mainly an orthogonal issue and the problems will
> happen with or without using gpgme. As GnuPG 2.2 is under way, it makes sense
Please note that 2.2 is more of a marketing term than a change. 2.1 is
already in use and will be the standard gpg version in several distros,
including Debian.
Interoperability with 1.4 is a bit cumbersome if you often add new keys.
However, "gpg --export | gpg1 --import" is not too complicated.
Be aware that ECC keys will be used more and more and they are not
supported by gpg1. Further we are currently defining a v5 key format to
be prepared for weaknesses in the SHA-1 based fingerprint. It is very
unlikely that a v6 key format will be added to gpg1.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2017-03-22 17:56 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 [this message]
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=87poh9p70n.fsf@wheatstone.g10code.de \
--to=wk@gnupg.org \
--cc=avarab@gmail.com \
--cc=bernhard.reiter@intevation.de \
--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).