Re: [Pyme-help] Constants for import/secret flag in key

[Igor B. <be...@us...>]

Stefan Neumann wrote:

>c) I really don't know. But renaming import to somethning like "_import"
>   is not elegant/smart.
>  
>
I'm leaning torward a solution where all constants live in 
pyme.constants package with just GPGME_ prefix stripped off. This way 
there's a smaller chance for a GPGME constant name to conflict with a 
python reserved word. It would require to use 'startswith' string method 
to loop over a particular set of constants but I hope it's a better 
solution then not being able to use some constants at all or to have an 
inconsistent mapping for some constants.

Let me know if you have any objection to this solution.

>>>2) secret flag in key
>>>      
>>>
>>Well... It looks like the   parameter to the
>>gpgme_op_keylist_start() which is the second parameter to
>>ctx.op_keylist_all() works not how it is described in 'info gpgme'.
>>According to what I see - True means to retrieve only secret keys and
>>False means to retrieve _only_ public keys. 
>>    
>>
>
>No, I don't think so:
>
>"
>[..]
>If SECRET_ONLY is not `0', the list is restricted to secret keys only.
>[..]
>"
>
>This works fine and correctly. Problem is, that depending on this
>parameter, the flag "secret" in the key is set. Actually, what i need,
>is for example:
>
>- Getting a list of all keys in the keyring.
>- Depending on the flag "secret" displaying one key or a key-pair(for
>  secret keys)
>
>But the problem is that the "secret"-flag depends on the parameter
>'SECRET_ONLY', which should be False according to list all keys.
>
>  
>
>>Some time ago I've accepted
>>it and didn't bother to push for a change in gpgme or update of its
>>documentation. If you think this is very important I can follow up on
>>gpgme list with such request.
>>    
>>
>
>I think, there is no need to change gpgme. It behaves correctly. The
>only question is, if this "flag-thing" is an pyme-eror, a gpgme-error or
>just the way, it should be
>  
>
Well... If it's an error - it's not a pyme error since pyme does nothing 
with this data - just converts it from a C structure into a Python 
object. What I was trying to say is that I think that what gpgme returns 
is better explained by assumption that with 'SECRET_ONLY' equal to 0 you 
get the list of 'public' keys and not 'public and secret' ones. Let me 
explain the flow of my thoughts...

In the gnupg keyrings you cannot have a secret key without a public one 
to pair with it. Therefore, the list of secret keys in a keyring is a 
subset of the list of public keys. When you retrieve a key in GPGME and 
then use it to encrypt, sign, or any other operation you acctually 
passes into gpg process not the key itself, but the ID of the key to be 
used for the operation and this ID is one for each pair of secret and 
public keys. When you retrieve keys with 'SECRET_ONLY' equal to 0 you 
will notice that all keys and subkeys have 'secret' equal to 0. When you 
retrieve keys with 'SECRET_ONLY' equal to 1 you will notice that the 
keys are the subset of those retrieved with 'SECRET_ONLY' equal to 0 and 
the only difference between present in both cases is the 'secret' field.

I think that confusion comes from the definition of the 'secret' field 
itself. I agree that it will be more useful if it would mean  'the key 
has both the public and secret part of the pair' instead of just 'the 
key is a secret key'. Unfortunately, it has the later meaning.

As for the solution to your problem - I solved it by having 2 runs - 
first, I retrieve keys with 'SECRET_ONLY' equal to 1 and then I retrieve 
keys with 'SECRET_ONLY' equal to 0 and keys whose IDs present in both 
cases I mark for key-pair display others - for one-key display. You can 
take a look at the PyGpa.load_keys() method defined in pygpa.py example.

Hope it helps,
Igor