fragility of --edit-key interface [was: Re: Changing trust in GPGME]

[Jameson Rollins]

On Wed, Jan 13, 2010 at 10:39:28AM +0100, Werner Koch wrote:
> On Tue, 12 Jan 2010 23:41:52 +0100, Piotr Bratkowski wrote:
> 
> > I have this code. And when I see output owner_trust = 4, but in gpg
> > from system I get 0. Do I need to somehow save this changes??
> 
> This is not directly supported by GPGME.  You need to write an edit
> interactor to control the gpg --edit-key command.  GPA has code which
> shows how to do it.

Hello Werner et. al.  My understanding is that one of the main
advantages of GPGME is that it provides a stable API to gnupg
functionality.  I understand that GPGME doesn't yet provide all the
functionality that a user might need, but I think that suggesting
developers use "gpg --edit-key" to achieve their desired functionality
should include a strong warning that the interface to "gpg --edit-key"
is fragile and may change unexpectedly and without warning.

For instance, as of v1.4.10 (and v2.0.13), the edit-key interface to
generate a subkey on an existing key ('addkey') in expert mode changed
such that the "RSA (set your own capabilities)" selection in the key
type chooser moved from entry 7 to entry 8.  As far as I can tell,
this change was not documented, at least not in the any of the
changelogs associated with recent gnupg releases.  The Monkeysphere
project [0] is using this capability and this undocumented change
recently caused problems.

Developers looking for the stable interface that GPGME is supposed to
provide should be duly warned that the "gpg --edit-key" interface is
not as stable, and that they should be on the look out for changes to
that interface in the future.

jamie.

[0] http://web.monkeysphere.info/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20100113/181b18bc/attachment.pgp>