Stable GnuPG interface, git should use GPGME
Werner Koch
wk at gnupg.org
Wed Mar 22 18:15:36 CET 2017
On Fri, 17 Mar 2017 10:56, bernhard.reiter at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: </pipermail/attachments/20170322/cd2e16de/attachment.sig>
More information about the Gnupg-devel
mailing list