Stable GnuPG interface, git should use GPGME

[Peter Lebbing]

On 22/03/17 18:15, Werner Koch wrote:
> It actually does.  For the tasks git uses gpg you should not notice a
> difference in gpgme between any of these versions.

Bernhard wrote "interoperability problems between [...] key stores". I'm
under the impression you are actually answering the question "can GPGME
be used in the same way regardless of the GnuPG version" instead?

> Interoperability with 1.4 is a bit cumbersome if you often add new keys.
> However, "gpg --export | gpg1 --import" is not too complicated. 

This presumes that

1) Keys are only updated on the 2.1 side
2) Keys are not deleted
3) Secret keys are never changed

right?

1) is trivially solvable. 2) is trickier, but can be done.

3) is because GnuPG 1.4 cannot update a secret key at all. Adding a new
subkey fails with:

gpg: key DCDFDFA4: already in secret keyring
gpg: Total number processed: 1
gpg:       secret keys read: 1
gpg:  secret keys unchanged: 1

You could delete before re-importing, but what if the key on the 1.4
side is actually the newer one? You'd lose all changes. Worst case:
updates of a single key on both sides. But that is perhaps pushing the
limit of sane use. Perhaps not, perhaps the user likes to use two
different frontends which use different GnuPG versions as their backend.

Luckily, expiration extensions are picked up by just transferring the
public key part of a secret key, so that does work.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170322/5cbddf88/attachment.sig>