gpgme 0.3.3 questions
stephane at sente.ch
Fri Sep 21 14:56:01 CEST 2001
> > - GpgmeData read callback: can the callback return no data, but
> > without being at EOF?
> * and the number actually read in @nread. It may return 0 in @nread
> * if there are no bytes currently available. To indicate EOF the
What's the point of returning 0, without being at EOF?
> > - gpgme_release_context() "releases all resources": what are these
> > resources? Keys, trustItems, datas?
> Everything you can access using that context.
But can I still use returned keys/trustItems/data if I
> > - GpgmeContext passphrase callback: can we expect to always have
> > description on three lines? "TRY_AGAIN" or "ENTER", userID or
> > ID hint missing]" (does it mean that keyID was not included?), ???
> > (what is it?) or "[passphrase info missing]", always unlocalized.
> Currently 3 lines, in future you might see more lines. The hint lines
> are not localized and are useful for a quick and dirty implementation.
> Those "missing" notices are probably due to gpg problems
> Don't put to much work into this, because eventually GpgAgent will
> take care of passphrase stuff.
It will be in gpg 1.1... When will it be out?
> > - After gpgme_op_import(), how can we get imported keys?
> To you want some notices about which keys are imported?
Yes, it would be nice if I could get the list of imported keys.
Maybe through the new "context operation status".
> > - GpgmeKey misses two functions: gpgme_key_subkeys_count() and
> > gpgme_key_userids_count(). We cannot base counts on results
> > by gpgme_key_get_ulong_attr() or gpgme_key_get_string_attr(),
> You can ask for attributes which do return valid informations.
> I will add attributes to get the count.
That's what I do currently: I enumerate valid info.
> > - Can subkeys be secret? If YES, then gpgme_key_get_ulong_attr()
> > gpgme_key_get_string_attr() return only main key secretness.
> Yes but if a main key is secret, the subkeys are also secret.
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.
> > - GpgmeData: currently there is no way to get data without it to be
> > released (gpgme_data_release_and_get_mem()).
> Use gpgme_data_read().
So, gpgme_data_release_and_get_mem() is a kind of shortcut.
> > - gpgme misses a way to edit keys
> It is on my todo list.
I hope it's high priority ;-) We miss it do create a PGP Key Manager
> > - It would be nice to be able to give other options to gpg with
> > gpgme, like throwKeyID, etc. (important for mails with BCC)
> I would not do a --throw-keyid for BCCs because the visible recipients
> get a clue that it is encoded for n other recipients - better encrypt
> it for BCCs separately.
I didn't think that the number of keys could be retrieved after
Thanks very much for your explanations,
More information about the Gnupg-devel