Re: Stable GnuPG interface, git should use GPGME

[Werner Koch <wk@gnupg.org>]

[-- 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 --]