a few GPGME issues

Werner Koch wk at gnupg.org
Mon Apr 22 09:51:02 CEST 2002

On Sun, 21 Apr 2002 20:58:17 +0200, Wichert Akkerman said:

> Unfortunately gpg-agent is mention in a few places in the documentation
> but has never been part of a proper release so I can't use that.

It is currently part of the newpg package
(ftp.gnupg.org/gcrypt/alpha/aegypten/newpg-*) which will eventually be
merged with GnuPG.  There used to be an old implementation of
gpg-agent which predated the one from the aegypten project - but this
one is deprecated.

gpg 1.0.7 (or the current snapshots) have support to use the gpg-agent
as to allow passphrase caching but this is not very well tested.  If
you want to deploy an in-house application, you should try it out -
having a Debian package might not be a good idea - I'd suggest to wait
until it is merged with GnuPG or make a gpg-agent only package from
newpg in the meantime.

> Bugger, that means that for now I'm going to have to resort to calling
> gnupg and using the command-fd and passphrase-fd stuff myself :(

Marcus, please check whether it really copies the passphrase data.
IIRC, I made it writing directly to the fd.  But well, quite some time
passed since I implemented it.

> Another approach would be to expose a file descriptor from GPGME where
> I can write the passphrase to from the callback. That would actually
> be even better since it means I can implement my own gpg-agent like
> thing (which I actually already have).

I have this in mind as an pragmatic way to access the key management
functions of gpg.  Designing a general API for this isn't that easy -
so the better way might indeed be to expose an command-fd/status-fd
API to let others come up with good code and later 5ake this the best
code and make an API out of it.  It would be very useful to have this
feature, so that we can use gpgme for GPA.

The passphrase callback is a different thing as it needs to handle
sensitive data.

I am going to discuss this with Marcus.

> Speaking of ABI and text-data: can you explain the reason for returning
> data in XML format instead of structs? I can understand it makes the ABI
> more stable, but it also means that an application will have to include

The idea was that some large systems already use XML to some extend so
it might be handy for them.  And it is quite nice for debugging gpgme.
There is also the gpgme_key_get_{ulong,string}_attr interface which
avoids the XML overhead as well as structures.


More information about the Gnupg-devel mailing list