gpgme 0.3.3 questions
wk at gnupg.org
Fri Sep 21 17:17:02 CEST 2001
On Fri, 21 Sep 2001 13:54:09 +0200, Stephane Corthesy said:
> What's the point of returning 0, without being at EOF?
It might choose to interrupt the read operation instead of waiting for
> But can I still use returned keys/trustItems/data if I
> retained/referenced them?
Sure. Consider GpgmeContext, GpgmeKey, GpgmeData all as independent
> It will be in gpg 1.1... When will it be out?
I don't known. I have to balance my time spend on pro bono work against
those which yield some revenue.
> Yes, it would be nice if I could get the list of imported keys.
> Maybe through the new "context operation status".
This should not grow indefinitely; I am not yet sure how to do it.
> So, this is a global attribute, isn't it? It has no sense to ask a
> subkey its secretness: we should ask the main key instead.
The flag just says: secret key available for this public key. Wether
you can access all subkeys is a different story - they might be
protected by different passphrases.
> So, gpgme_data_release_and_get_mem() is a kind of shortcut.
Yeah, it can just use the memory already allocated by gpgme for the data.
> I hope it's high priority ;-) We miss it do create a PGP Key Manager
IIRC, Timo has some patches but I want a protocol independent
interface for this.
> I didn't think that the number of keys could be retrieved after
Well, the encrypted data is still available - other wise it would not
be possible to decrypt it. The way it works is that a session is used
to encrypt the message and this session key is then public key
encrypted for each recipient. --throw-keyid just removes the keyid of
the recipient, so that he has to try all his secret keys to decrupt
it, but all those encrypted session keys are visible.
> Thanks very much for your explanations,
Werner Koch Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions -- Augustinus
More information about the Gnupg-devel