gpgme 0.3.3 questions

[Stephane Corthesy]

Hi,

> > - 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  
retained/referenced them?

> > - GpgmeContext passphrase callback: can we expect to always have   
> > description on three lines? "TRY_AGAIN" or "ENTER", userID or  
"[User
> > 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  
returned
> > by gpgme_key_get_ulong_attr() or gpgme_key_get_string_attr(),  
because
>
> 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()  
and
> > 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  
application.

> > - 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  
--throw-keyid...


Thanks very much for your explanations,

Stephane