pyme-help

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

[Stefan N. <ste...@fr...>]

Hi,

it's me again ;-)

So, I have just two question:

1) Constants for import

I think, this is based on the analogie how you make constants available.
I need the GPGME_IMPORT_SECRET constant. I will find it in:

pyme.constants.import

Problem:
========

>>> import  pyme.constants.import.SECRET
  File "<stdin>", line 1
    import  pyme.constants.import.SECRET
                                ^
SyntaxError: invalid syntax


OR:

>>> pyme.constants.import.SECRET
  File "<stdin>", line 1
    pyme.constants.import.SECRET
                        ^
SyntaxError: invalid syntax

OR

... (could be continued in all different import styles ;-) )


Reason:
=======

"import" is a reserved word and cannot be used in this way.

Solving:
========

Up to you. "import" must have a different name. (Or do i make a mistake?)


2) secret flag in key

Looking at this code snipplet:

###########################################################

def getKey(email,secret):
    """
    get Key for a specific e-Mail-adress. Result is the original gpg-Key

    email - used as identifier
    secret - should be a secret key
    """


    ctx = core.Context()

    keylist=ctx.op_keylist_all(email,secret)
    return keylist.next()

###########################################################

Every Key has a flag, if this key is a secret key.

The problem is now, that I get this depending on the parameter secret:


>>> key=getKey("ste...@fr...",True)
>>> key.secret
1
>>> key=getKey("ste...@fr...",False)
>>> key.secret
0

Is this a correct behaviour?


Thanks for your help

cheers,
	
	Stefan

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

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

Stefan Neumann wrote:

>1) Constants for import
>
>  
>
>>>>import  pyme.constants.import.SECRET
>>>>        
>>>>
>  File "<stdin>", line 1
>    import  pyme.constants.import.SECRET
>                                ^
>SyntaxError: invalid syntax
>  
>
Yes, I noticed this problem as well. I'm still thinking about what will 
be a good solution. I don't like change package name just for one type 
of constant and I don't like changing name for all constants...

> 2) secret flag in key
>
>Looking at this code snipplet:
>
>###########################################################
>
>def getKey(email,secret):
>    """
>    get Key for a specific e-Mail-adress. Result is the original gpg-Key
>
>    email - used as identifier
>    secret - should be a secret key
>    """
>
>
>    ctx = core.Context()
>
>    keylist=ctx.op_keylist_all(email,secret)
>    return keylist.next()
>
>###########################################################
>
>Every Key has a flag, if this key is a secret key.
>
>The problem is now, that I get this depending on the parameter secret:
>
>
>  
>
>>>>key=getKey("ste...@fr...",True)
>>>>key.secret
>>>>        
>>>>
>1
>  
>
>>>>key=getKey("ste...@fr...",False)
>>>>key.secret
>>>>        
>>>>
>0
>
>Is this a correct behaviour?
>  
>
Well... It looks like the 'SECRET_ONLY' 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. 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.

Igor

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

[Stefan N. <ste...@fr...>]

Igor Belyi wrote:
> Yes, I noticed this problem as well. I'm still thinking about what will
> be a good solution. I don't like change package name just for one type
> of constant and I don't like changing name for all constants...

Yes, that is probably not easy to decide but it has to be done. What
kind of possibilities do you/we have?

a) We can rename just the import file to IMPORT
   Problem: missing semantic

b) We can captilize all constant files
   =3D=3D> A lot of work

c) I really don't know. But renaming import to somethning like "_import"
   is not elegant/smart.

>> 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.=20

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

Thanks for your help

	Stefan


--=20

Stefan Neumann
Dipl.-Ing. (FH)

freiheit.com technologies gmbh
Stra=DFenbahnring 22 / 20251 Hamburg, Germany
fon       +49 (0)40 / 890584-0
fax       +49 (0)40 / 890584-20

1CB2 BA3C 168F 0C2B 6005 FC5E 3EBA BCE2 1BF0 21D3

B=FCcher kaufen und Freie Software f=F6rdern | http://bookzilla.de/

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