Re: Stable GnuPG interface, git should use GPGME

From: Werner Koch <wk@gnupg.org>
Date: Mar 22, 2017, 17:15 UTC
Message-ID: <87poh9p70n.fsf@wheatstone.g10code.de>
In-Reply-To: <201703171056.10468.bernhard.reiter@intevation.de>

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.