a few GPGME issues

[Marcus Brinkmann]

Hi Wichert,

On Sun, Apr 21, 2002 at 02:27:00PM +0200, Wichert Akkerman wrote:
> I've been looking at GPGME to see if I can use it to implement a tool
> to easily create detached signatures for a large number of files.

Just as a remark, at some time we will have a new server mode in GPG used by
GPGME that makes it possible to encrypt many times in a single session,
which will greatly improve performance.  Not available yet, but it will be
done transparently (as long as you don't destroy the context for every
operation).

> * I need to be able to copy the data buffer with the generated signature
>   (and modify it, the buffer does not seem to be zero-terminated which is
>   somewhat unpractical considering it is a string). Since it seems to
>   be impossible to get the size of the data in a buffer this is impossible.

The usual way to do this is to use gpgme_data_release_and_get_mem, which
returns the size of the buffer.  The alternative is to perform a
gpgme_data_rewind operation and then read it out with gpgme_data_read, just
as a file.  The former is more convenient.  You can then call realloc on the
buffer, too.
 
> * In order to conveniently sign a large number of files I have to store the
>   passphrase in memory.

I think this will be addressed better by gpg-agent, which, as ssh-agent,
can be run as a daemon and cache the passphrase.  I am not sure if full
support for gpg-agent is in the current gpg snapshot, but we are using it
for gpgsm already and there it works.  In this case, the passphrase will be
retrieved securely via the pinentry and stored by gpg-agent, so that you
won't have to use the passphrase callback at all.

The other way to get this information is to look at the result of the
operation, if it is No_Passphrase, you know that there has not been a useful
passphrase supplied by the user.  This information is not made available to
you at the time you would like to have it (when the passphrase callback is
called for clean up), but the whole passphrase callback is a bit of a hack
anyway, compared with gpg-agent.

In fact, gpgsm doesn't support using the passphrase callback (at least right
now, not sure what the future plan is).

> * The GPGME manual does not indicate how the passphrase that the callback
>   returns is used. Can I be sure that GPGME will never copy it and directly
>   write it a a passphrase filedescriptor?

Ah, good question.  It does indeed copy the data.  Another reason to use
gpg-agent.  In fact, it is not nice that it is doing that, but it seems to
be difficult to avoid given the current command handler interface.
 
> * I wanted to use the HOOK data for the passphrase callback to store some
>   data associated with the callback I am using. However GPGME only has a
>   function to set the callback and HOOK data but none to retrieve their
>   current values. This means I need to keep track of that data in another
>   place as well and create another abstraction layer around GPGME. Can
>   a function to retrieve that data please be added? This hold for both
>   passphrase and progess meter callbacks.

Mmmh, ok.  It would be convenient to have the set function return the old
value, supposing that this is good enough for you.  But as there are two
values to give back this doesn't work too well anyway.  I suppose

void gpgme_get_passphrase_cb (GpgmeCtx ctx, GpgmePassphraseCb *cb, void **hook)

will do the job for you (resp for progress meter)?

> * according to the documentation the DESC parameter of the passphrase callback
>   contains a text `usable to be displayed to the user of the application'.
>   I fail to see how a combination of numbers and strings without any
>   documentation what they mean is something you ever want to show to a user.
>   It woud be useful to be able to get the information contained in DESC
>   in a simple struct so we can use it in the callback without having
>   to parse the text.

Mmh, yeah, point taken.  However, I would like to discuss the future of the
passphrase interface with Werner first, in case it is going to be phased out
entirely in favor for gpg-agent.  Changing this requires adding a new
Passphrase callback type, and new set/get functions for them.  Or changing
the existing type of course, which would be an ABI change.  Definitely
something we will do more resistantly than the above natural extension to
get the cb function and the hook.

Thanks,
Marcus



-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus at gnu.org
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de