pyme-help — Help for PyMe users

Re: [Pyme-help] Re: FTBFS: 'alloc2' undeclared

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

Igor Belyi wrote:
> I'm still trying to find the right workaround for this. For now it 
> seems SWIG 1.3.28 is not good
> version to use for pyme build.
I've got it! Here's a slightly better patch which should not break back 
compatibility and does not use
undocumented features. I'm making similar changes in CVS as well.

Cheers,
Igor

[Pyme-help] Re: FTBFS: 'alloc2' undeclared

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

OK, I've looked at it and I'm sorry to say I don't think this is the 
right patch.

It seems to me that the patch disables gpgme.i's "const char *" typemap 
definition by using
SWIG's bug of not reporting invalid syntax but silently ignoring it to 
work around another SWIG
bug of the typemap causing alloc2 and buf2 not to be declared while 
statements freeing them to be
present.

I'm still trying to find the right workaround for this. For now it seems 
SWIG 1.3.28 is not good
version to use for pyme build.

Thanks for finding this out! :-)
Igor

Arnaud Fontaine wrote:
> Hello,
>
> This bug  [0] is due  to swig upgrade.  Actually, pyme builds  fine with
> swig <  1.3.28. In swig 1.3.28,  there is a new  option, namely 'match',
> for typemaps.
>
> I have attached the patch which  fixes this bug. I have built and tested
> pyme successfully using this patch.  Could you please make an upgrade of
> pyme for  swig 1.3.28 ? Thanks  a lot to  Manuel Menal for his  help for
> tracking the bug.
>
> Regards,
> Arnaud Fontaine
>
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358648
>
>   
> ------------------------------------------------------------------------
>
> --- gpgme.i.old	2006-04-02 16:23:02.000000000 +0200
> +++ gpgme.i	2006-04-02 15:43:27.000000000 +0200
> @@ -23,7 +23,7 @@
>  
>  // Allow use of None for strings.
>  
> -%typemap(python,in) const char * {
> +%typemap(match="in") const char * {
>    if ($input == Py_None)
>      $1 = NULL;
>    else if (PyString_Check($input))
>   

[Pyme-help] Re: FTBFS: 'alloc2' undeclared

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

Sorry, I'm on LinuxWorld Expo this week and won't be able to look at 
this until next week. If this switch appears just in 1.3.28 swig then 
the change should be a little bit bigger for back compatibility. 
Shortly, I greatly appreciate the patch - it gives me the right 
direction where I need to look for details.

Thanks,
Igor

Arnaud Fontaine wrote:
> Hello,
>
> This bug  [0] is due  to swig upgrade.  Actually, pyme builds  fine with
> swig <  1.3.28. In swig 1.3.28,  there is a new  option, namely 'match',
> for typemaps.
>
> I have attached the patch which  fixes this bug. I have built and tested
> pyme successfully using this patch.  Could you please make an upgrade of
> pyme for  swig 1.3.28 ? Thanks  a lot to  Manuel Menal for his  help for
> tracking the bug.
>
> Regards,
> Arnaud Fontaine
>
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358648
>
>   
> ------------------------------------------------------------------------
>
> --- gpgme.i.old	2006-04-02 16:23:02.000000000 +0200
> +++ gpgme.i	2006-04-02 15:43:27.000000000 +0200
> @@ -23,7 +23,7 @@
>  
>  // Allow use of None for strings.
>  
> -%typemap(python,in) const char * {
> +%typemap(match="in") const char * {
>    if ($input == Py_None)
>      $1 = NULL;
>    else if (PyString_Check($input))
>   

[Pyme-help] Re: pyme question

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

Jochen Sch=F6nfelder wrote:

>looks to me as if op_verify(signature,text,dummy) doesn't work.. it =
reads the
>signature, but seems to ignore the text, as I don't have to rewind i=
t, to read
>it's contents...
>
>example session:
>------------------------------------------------
> =20
>
>>>>c.op_verify(signature,text,dummy)
>>>>dummy.read()
>>>>       =20
>>>>
To verify detached signature you need use c.op_verify(signature, text=
,=20
None) and then call c.op_verify_result() to verify result.

Whenever in 'info gpgme' they say 'null pointer' it should be None in=
 PyMe.

For attached (normal) signatures you would use c.op_verify(signature,=
=20
None, dummy) to get clear text in dummy which would need to be rewind=
ed=20
afterwards.

Hope it helps,
Igor

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

Re: [Pyme-help] Problems with import

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

Stefan Neumann wrote:

>Hi,
>
>I just have another problem:
>
>Whem I am importing keys from an file, i need the information, which
>keys are imported. This function looks like this:
>
>*************************************
>
>def importFromFile(data):
>    """
>    Importing a key from a string.
>
>    Parameters:
>
>    data - The data as a string
>    """
>
>    c=core.Context()
>    keydata = core.Data(data)
>    c.op_import(keydata)
>    result = c.op_import_result()
>    return result
>
>*************************************
>
>Now I have to examine the result:
>(I subsitute the >>> to $)
>
>$ result=crypto.importFromFile(keys)
>$ result.imported
>25
>
>
>Then I want iterate over the list of imported keys:
>
>
>$ print result.imports
><pyme.gpgme._gpgme_import_statusPtr; proxy of C _gpgme_import_status
>instance at _d0781408_p__gpgme_import_status>
>
>(It is not None)
>
>$ for imp in result.imports:
>...    print imp.fpr
>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>TypeError: iteration over non-sequence
>
>This should be the first error. Like mentioned in the
>gpgme-documentation, it should be a list, so i should be able to iterate
>over the list.
>  
>
Well... In gpgme-documentation when then say 'list' they mean the 
'linked-list' where next element is refered by a 'next' pointer. It 
would probably be useful to convert this gpgme_import_status_t type 
field into a 'list' in Python meaning but this may require to have a 
separate PyMe class for the gpgme_import_result_t type as well. So far 
PyMe was successful in creating only a few classes allowing SWIG to 
create the rest of them automagically. I do like the good idea of 
converting all 'linked lists' into 'python lists'. I'll try to think of 
a solution for this which won't conflict with the PyMe idea of keeping 
the Python wrapper code small.

>The second problem is, that the result-information is totally corrupted:
>
>$ result.imports.fpr
>'`\xce\xbc\xb7\xb1'
>
># This is not a real fpr
>
>$ result.imports.next.fpr
>segmentation fault
>  
>
About that I don't know... If the data passed in the 'keys' variable was 
bad it was supposed to generate an exception during  import and not 
return a corrupt value as a result. Have you tried the 
examples/exportimport.py script? If you have a problem even with this 
script then something in pyme or python setup is wrong or at least 
different then in my setup. If not - it's the data you are passing into 
import which causes the problem and reveals a bug in pyme, gpgme, 
python, or in all three of them and it will be a good idea to show the 
data itself.

Cheers,
Igor

[Pyme-help] Problems with import

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

Hi,

I just have another problem:

Whem I am importing keys from an file, i need the information, which
keys are imported. This function looks like this:

*************************************

def importFromFile(data):
    """
    Importing a key from a string.

    Parameters:

    data - The data as a string
    """

    c=3Dcore.Context()
    keydata =3D core.Data(data)
    c.op_import(keydata)
    result =3D c.op_import_result()
    return result

*************************************

Now I have to examine the result:
(I subsitute the >>> to $)

$ result=3Dcrypto.importFromFile(keys)
$ result.imported
25


Then I want iterate over the list of imported keys:


$ print result.imports
<pyme.gpgme._gpgme_import_statusPtr; proxy of C _gpgme_import_status
instance at _d0781408_p__gpgme_import_status>

(It is not None)

$ for imp in result.imports:
...    print imp.fpr

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: iteration over non-sequence

This should be the first error. Like mentioned in the
gpgme-documentation, it should be a list, so i should be able to iterate
over the list.

The second problem is, that the result-information is totally corrupted:

$ result.imports.fpr
'`\xce\xbc\xb7\xb1'

# This is not a real fpr

$ result.imports.next.fpr
segmentation fault

I hope, you can help me.

greets
	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

[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:

>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

[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] Export public keys with keyid

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

Igor Belyi wrote:

> The problem is that you forgot to 'rewind' the key back to the beginning
> before reading from it.

Oh yes. Damn! ;-) I should have recognized it earlier. Yes, now it
works.(It was a  bit late yearterday ;-) )

> Also note that c.op_export() does not return anything - all errors are
> reported via exceptions. Therefore, the more appropriate way to catch an
> error in your case is as follows:
> 
> try:
>    c.op_export(keyid,0,key)
> except errors.GPGMEError, ex:
>    print ex.getstring()

Thanks. I was questioning myself everytime I read the
gpgme-documentation and thought, I should test the result of the call.
But now,... great. Actually, it is quite the logical way to do it like this!

> Hope it helps,

It helped a lot!

> Igor

cheers
	Stefan

[Pyme-help] Re: hello, it's me again about pyme and some questions about Windows

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

Nikos Kouremenos wrote:

> GNUPGInterface scans output of GPG right?
>
>Pyme speaks to GPGME which does what? (apart from being "easy")
>  
>
Well... The sad part is that GPGME also starts a separate GPG process 
and communicates with it via pipes. It's mostly the "easy" part which 
separates it from GNUPGInterface. Another difference is that both GPGME 
and GNUPG are maintained by the same team which makes you hope that 
communication between these 2 components will be kept in sync without 
any changes to PyMe.

Plus, there's a talk of having part of GNUPG code working with the 
keyrings to be moved into a separate library and then GPGME could be 
rewritten using this future library directly instead of starting a 
separate GPG process. Hopefully, the GPGME interface will be left the same.

As for my status of compilation under Windows - I have PyMe and GPGME 
compiled under cygwin, but it makes it dependent on number of other 
CygWin DLLs. I'm trying to compile GPGME with mingw now but ran into 
strange problems which probably related to the communication between 
GPGME and the started GPG. I'm still investigating it.

Cheers,
Igor

Re: [Pyme-help] Export public keys with keyid

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

Stefan Neumann wrote:

>####
>def exportKey(keyid):
>
>    c = core.Context()
>    c.set_armor(True)
>    key = core.Data()
>    print c.op_export(keyid,0,key)
>
>    return key.read()
>####
>
>result:
>  
>
>>>>exportKey("1bf021d3")
>>>>        
>>>>
>None
>''
>  
>
>
>####
>  
>
The problem is that you forgot to 'rewind' the key back to the beginning 
before reading from it.

A key in PyMe is a stream of data. When you write something into it the 
current possition changes. The next read operation will read from the 
current possition and not from the start. To fix your code you need to 
add 'key.seek(0,0)' before key.read().

Also note that c.op_export() does not return anything - all errors are 
reported via exceptions. Therefore, the more appropriate way to catch an 
error in your case is as follows:

try:
    c.op_export(keyid,0,key)
except errors.GPGMEError, ex:
    print ex.getstring()

Hope it helps,
Igor

[Pyme-help] Export public keys with keyid

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

Hi,
I just have a tiny problem and i want to check, if you the same problem.
I neede to export the public key and want to identify it with its keyid.
This is the code:

####
def exportKey(keyid):

    c =3D core.Context()
    c.set_armor(True)
    key =3D core.Data()
    print c.op_export(keyid,0,key)

    return key.read()
####

result:
>>> exportKey("1bf021d3")
None
''
>>>

####

So, actually, the result of the operation is None and the keydata is
empty. Is a problem with gpgme?

I use:

pyme 0.7
gnupg 1.4.2
gpgme 1.1.0

cheers

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/

[Pyme-help] Re: hello, it's me again about pyme and some questions about Windows

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

I haven't compiled pyme for Windows yet, so a simple answer is that pyme 
for Windows does not exist yet.
On the other hand, since somebody is interested in this I can try to do 
the build over this weekend.
As for alternatives - other then the way GNUPGInterface works I don't 
see any.

Cheers,
Igor

Nikos Kouremenos wrote:

>can I use pyme in Windows for Gajim(.org)?
>
>I'm not happy with what we do either in GNU/Linux but at least it
>works (we use GNuPGInterface which apparently scans stdout of gpg and
>always passed the passphrase in CLI everytime etc)
>
>Have fun.
>
>moreover, if pyme cannot do it (I reall yhope it can) any others idea
>you may have to suggest me?
>
>Thanks!
>--
>Nikos Kouremenos | Jabber ID: nk...@ja... | http://members.hellug.gr/nkour
>  
>

apt-able repository for pyme available (was: Re: [Pyme-help] patch for debian/ directory in CVS)

[Joost v. B. <j.e...@uv...>]

Hi Igor,

On Sun, Jul 31, 2005 at 11:17:24PM -0400, Igor Belyi wrote:
> Joost van Baal wrote:
>=20
> >I've prepared a patch for the stuff in debian/ in CVS.  (I plan to do
> >some development with pyme, for my project on
> >http://non-gnu.uvt.nl/pub/mailman/ .)
> >=20
> >
> Joost, thanks for the patch. I've incorporated changes making use of=20
> dh_python and moving pyme into 'python'
> Section into CVS.

Thanks!

> >PS: I saw pyme is no longer distributed with Debian.  Is there another
> >place where fresh Debian pyme packages get uploaded?
> >=20
> >
> I never actually saw pyme to be distributed with Debian.

Well, it _was_ distributed with Debian from 2002-11 untill 2003-10,
see http://bugs.debian.org/213124 .

> I mainly=20
> maintain debian directory since it simplifies
> installation for my friends.

OK.

> On the other hand, I understand that Ubuntu distribution had plans to=20
> include pyme into the list of their
> packages. I would advise to check with them.

I've found a mirror of your CVS stuff on
http://arch.ubuntu.com/py...@ar... .  (FWIW: one needs tla >=3D
1.3.3 to check this archive out.  With such a GNU Arch client, one can
do

 % tla register-archive http://arch.ubuntu.com/py...@ar...
 % tla get py...@ar.../pyme--MAIN--0 pyme

to get a copy of the archive.  The name will get changed to
bazaar.ubuntu.com one day, I've been told.)

I couldn't find any work from the Ubuntu guys however: the Arch
repository is set up to do CVS imports only.  Ubuntu doesn't yet have a
public repository of its work; they're working on it.

Do you happen to know which Ubuntu-developer is (planning to) work on
the package?

Anyway, I've made some other minor changes to your package.  The result
is now apt-able: Add

 deb http://non-gnu.uvt.nl/debian sarge pyme
 deb-src http://non-gnu.uvt.nl/debian sarge pyme

to your /etc/apt/sources.list, and

 apt-get install python-pyme

gets you going.

If you like my work in a patch, tell me.  I'll likely do some other
minor work on the Debian package soonish:  Check for compliancy with
newer Debian standards than 3.5.2, and deal with {post,pre}{inst,rm}
files.

Bye,

Joost

--=20
Joost van Baal                            http://abramowitz.uvt.nl/
                                                 Tilburg University
j.e...@uv...                                  The Netherlands

Re: [Pyme-help] buggy when in mod_python

[Dave B. <da...@br...>]

Igor Belyi wrote:
> Dave Brondsema wrote:
>
>> When I run the attached code from the commandline, it succesfully
>> verifies the detached signature.  When I run it in mod_python, I get:
>>
>>
>> Mod_python error: "PythonHandler server"
>>
>> Traceback (most recent call last):
>>
>>   File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line
>> 287, in HandlerDispatch
>>     log=debug)
>>
>>   File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line
>> 457, in import_module
>>     module = imp.load_module(mname, f, p, d)
>>
>>   File "/home/dpb2/public_html/pyme_problem/server.py", line 35, in ?
>>     handler()
>>
>>   File "/home/dpb2/public_html/pyme_problem/server.py", line 28, in
>> handler
>>     raise Exception("No PGP signature found in: " + content + stext)
>>
>> Exception: No PGP signature found ...
>>
>>
>>
>> I am running Pyme 0.7.0, Apache 2.0.54, mod_python 3.1.3, Python 2.3.5
>> Why doesn't this work in mod_python?
>
>
> My guess is that the user which you use when running the code from the
> commandline and the user which runs apache
> are different. When GNUPGHOME env. var. is not set its value is assumed
> to be $HOME/.gnupg . The files where public
> and secret keys are looked in are $GNUPGHOME/pubring.gpg and
> $GNUPGHOME/secring.gpg.
>
> Hope it helps,
> Igor
>

That seems to work, thanks.  Now on to other problems... :-)

--
Dave Brondsema : da...@br...
http://www.splike.com : programming
http://www.brondsema.net : personal
                <><

Re: [Pyme-help] buggy when in mod_python

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

Dave Brondsema wrote:

> When I run the attached code from the commandline, it succesfully
> verifies the detached signature.  When I run it in mod_python, I get:
>
>
> Mod_python error: "PythonHandler server"
>
> Traceback (most recent call last):
>
>   File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line
> 287, in HandlerDispatch
>     log=debug)
>
>   File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line
> 457, in import_module
>     module = imp.load_module(mname, f, p, d)
>
>   File "/home/dpb2/public_html/pyme_problem/server.py", line 35, in ?
>     handler()
>
>   File "/home/dpb2/public_html/pyme_problem/server.py", line 28, in 
> handler
>     raise Exception("No PGP signature found in: " + content + stext)
>
> Exception: No PGP signature found ...
>
>
>
> I am running Pyme 0.7.0, Apache 2.0.54, mod_python 3.1.3, Python 2.3.5
> Why doesn't this work in mod_python?

My guess is that the user which you use when running the code from the 
commandline and the user which runs apache
are different. When GNUPGHOME env. var. is not set its value is assumed 
to be $HOME/.gnupg . The files where public
and secret keys are looked in are $GNUPGHOME/pubring.gpg and 
$GNUPGHOME/secring.gpg.

Hope it helps,
Igor

[Pyme-help] buggy when in mod_python

[Dave B. <da...@br...>]

When I run the attached code from the commandline, it succesfully
verifies the detached signature.  When I run it in mod_python, I get:


Mod_python error: "PythonHandler server"

Traceback (most recent call last):

   File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line
287, in HandlerDispatch
     log=debug)

   File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line
457, in import_module
     module = imp.load_module(mname, f, p, d)

   File "/home/dpb2/public_html/pyme_problem/server.py", line 35, in ?
     handler()

   File "/home/dpb2/public_html/pyme_problem/server.py", line 28, in handler
     raise Exception("No PGP signature found in: " + content + stext)

Exception: No PGP signature found ...



I am running Pyme 0.7.0, Apache 2.0.54, mod_python 3.1.3, Python 2.3.5
Why doesn't this work in mod_python?

Thanks!


--
Dave Brondsema : da...@br...
http://www.splike.com : programming
http://www.brondsema.net : personal
                <><

Re: [Pyme-help] patch for debian/ directory in CVS

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

Joost van Baal wrote:

>I've prepared a patch for the stuff in debian/ in CVS.  (I plan to do
>some development with pyme, for my project on
>http://non-gnu.uvt.nl/pub/mailman/ .)
>  
>
Joost, thanks for the patch. I've incorporated changes making use of 
dh_python and moving pyme into 'python'
Section into CVS.

>PS: I saw pyme is no longer distributed with Debian.  Is there another
>place where fresh Debian pyme packages get uploaded?
>  
>
I never actually saw pyme to be distributed with Debian. I mainly 
maintain debian directory since it simplifies
installation for my friends.

On the other hand, I understand that Ubuntu distribution had plans to 
include pyme into the list of their
packages. I would advise to check with them.

Cheers,
Igor

[Pyme-help] patch for debian/ directory in CVS

[Joost v. B. <j.e...@uv...>]

Hi,

I've prepared a patch for the stuff in debian/ in CVS.  (I plan to do
some development with pyme, for my project on
http://non-gnu.uvt.nl/pub/mailman/ .)

I haven't tested it yet but would like to share it before I leave
for about a week...

Bye,

Joost

PS: I saw pyme is no longer distributed with Debian.  Is there another
place where fresh Debian pyme packages get uploaded?

-------------------------------------------------------------------

Index: changelog
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/pyme/pyme/debian/changelog,v
retrieving revision 1.10
diff -u -r1.10 changelog
--- changelog	27 Apr 2005 21:37:05 -0000	1.10
+++ changelog	26 Jul 2005 15:39:10 -0000
@@ -1,3 +1,14 @@
+pyme (0.7.0.1) unstable; urgency=3Dlow
+
+   * debian/control: added new download location.
+   * Applied patches prepared by Matthias Klose on 28 Sep 2003 for
+     pyme 0.5.1.1, see bug #213124:
+     - Update python-pyme to use python2.3 as the default python version.
+     - Change package section to python.
+     - Make description more verbose (would have closed bug 209877).
+
+ -- Joost van Baal <jo...@uv...>  Tue, 26 Jul 2005 17:18:48 +0200
+
 pyme (0.7.0) unstable; urgency=3Dlow
=20
   * Removed workaround in Context.wait()
Index: control
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/pyme/pyme/debian/control,v
retrieving revision 1.3
diff -u -r1.3 control
--- control	18 Mar 2005 19:09:28 -0000	1.3
+++ control	26 Jul 2005 15:39:11 -0000
@@ -1,18 +1,19 @@
 Source: pyme
-Section: libs
+Section: python
 Priority: optional
 Maintainer: Igor Belyi <be...@us...>
-Build-Depends: debhelper (>> 3.0.0), python2.2-dev, python2.3-dev, python2=
=2E4-dev, libgpgme11-dev, swig
+Build-Depends: debhelper (>> 4.1.67), python, python2.2-dev, python2.3-dev=
, python2.4-dev, libgpgme11-dev, swig
 Standards-Version: 3.5.2
=20
 Package: python-pyme-doc
 Architecture: all
 Description: Python interface to the GPGME GnuPG encryption library
- This package contains the documentation for Pyme.
+ This package contains the documentation for Pyme, an interface to the
+ GPGME GnuPG encryption library.
=20
 Package: python-pyme
 Architecture: all
-Depends: python2.4-pyme
+Depends: ${python:Depends}
 Suggests: python-pyme-doc
 Description: Python interface to the GPGME GnuPG encryption library
  This is a "dummy" package that will cause the Pyme package for Debian's
@@ -30,15 +31,15 @@
  for C.
  .
  Features:
- * Feature-rich, full implementation of the GPGME library.  Supports
-   all GPGME features except interactive editing (coming soon).
-   Callback functions may be written in pure Python.
+   * Feature-rich, full implementation of the GPGME library.  Supports
+     all GPGME features except interactive editing (coming soon).
+     Callback functions may be written in pure Python.
  .
- * Ability to sign, encrypt, decrypt, and verify data.
+   * Ability to sign, encrypt, decrypt, and verify data.
  .
- * Ability to list keys, export and import keys, and manage the keyring.
+   * Ability to list keys, export and import keys, and manage the keyring.
  .
- * Fully object-oriented with convenient classes and modules.
+   * Fully object-oriented with convenient classes and modules.
  .
  This package is for Python 2.2.
=20
@@ -54,15 +55,15 @@
  for C.
  .
  Features:
- * Feature-rich, full implementation of the GPGME library.  Supports
-   all GPGME features except interactive editing (coming soon).
-   Callback functions may be written in pure Python.
+   * Feature-rich, full implementation of the GPGME library.  Supports
+     all GPGME features except interactive editing (coming soon).
+     Callback functions may be written in pure Python.
  .
- * Ability to sign, encrypt, decrypt, and verify data.
+     * Ability to sign, encrypt, decrypt, and verify data.
  .
- * Ability to list keys, export and import keys, and manage the keyring.
+     * Ability to list keys, export and import keys, and manage the keyrin=
g.
  .
- * Fully object-oriented with convenient classes and modules.
+     * Fully object-oriented with convenient classes and modules.
  .
  This package is for Python 2.3.
=20
@@ -78,15 +79,15 @@
  for C.
  .
  Features:
- * Feature-rich, full implementation of the GPGME library.  Supports
-   all GPGME features except interactive editing (coming soon).
-   Callback functions may be written in pure Python.
+   * Feature-rich, full implementation of the GPGME library.  Supports
+     all GPGME features except interactive editing (coming soon).
+     Callback functions may be written in pure Python.
  .
- * Ability to sign, encrypt, decrypt, and verify data.
+   * Ability to sign, encrypt, decrypt, and verify data.
  .
- * Ability to list keys, export and import keys, and manage the keyring.
+   * Ability to list keys, export and import keys, and manage the keyring.
  .
- * Fully object-oriented with convenient classes and modules.
+   * Fully object-oriented with convenient classes and modules.
  .
  This package is for Python 2.4.
=20
Index: copyright
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/pyme/pyme/debian/copyright,v
retrieving revision 1.3
diff -u -r1.3 copyright
--- copyright	21 Apr 2005 03:53:11 -0000	1.3
+++ copyright	26 Jul 2005 15:39:11 -0000
@@ -3,6 +3,8 @@
 This package was debianized by John Goerzen <jgo...@co...> on
 Tue, 19 Nov 2002 14:32:36 -0600.
=20
+It was downloaded from http://sourceforge.net/projects/pyme/ .
+
 Copyright:
=20
 Copyright (C) 2004 Igor Belyi <be...@us...>
Index: docs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/pyme/pyme/debian/docs,v
retrieving revision 1.2
diff -u -r1.2 docs
--- docs	20 Mar 2004 04:47:41 -0000	1.2
+++ docs	26 Jul 2005 15:39:11 -0000
@@ -1 +1 @@
-doc
+doc/*
Index: rules
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/pyme/pyme/debian/rules,v
retrieving revision 1.4
diff -u -r1.4 rules
--- rules	18 Mar 2005 19:09:28 -0000	1.4
+++ rules	26 Jul 2005 15:39:11 -0000
@@ -92,6 +92,7 @@
 	dh_compress -i
 	dh_fixperms -i
 #	dh_makeshlibs
+	dh_python -i
 	dh_installdeb -i
 #	dh_perl
 	dh_shlibdeps -i
@@ -122,6 +123,7 @@
 	dh_compress -a
 	dh_fixperms -a
 #	dh_makeshlibs
+	dh_python -a
 	dh_installdeb -a
 #	dh_perl
 	dh_shlibdeps -a


-------------------------------------------------------------------

--=20
Joost van Baal                            http://abramowitz.uvt.nl/
                                                 Tilburg University
j.e...@uv...                                  The Netherlands

[Pyme-help] pyme-0.7.0 announcement.

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

PyMe 0.7.0 is released. The major reason for going from 0.6 revision to
0.7 is the change in license from GPL to LGPL.

Release Note:

Bug fixes and license change release.

PyMe now is distributed under LGPL license due to a request. Note that
examples are still under GPL.

Added another fun example called pygpa. It implements gpa functionality
using pyme and pygtk. It even uses gpa translation files. And again, this is
just to illustrate that this can be done but pygpa is slower than gpa and it
does not implement work with key servers or backup of security keys
since those functions are not in GPGME and therefore are not PyMe related.

Small changes in APIs:
- passphrase_cb got previously missing 'prev_bad' argument to match the
signature
declared in GPGME.
- If user parameter specified during callback registration is not
present or is None, it
will NOT be passed into callback at all. This is a cleaner way to do
things in python
but may break your code if you had 'hook' to be a mandatory argument.
- core.wait() now always return tuple, so that on timeout it returns
(None, 0) instead of
just None.
- wait() and op_edit() now raise an exception on errors.

PyMe maintainer

Re: [Pyme-help] Re: PyME: Segmentation Faults

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

Robin Brandt wrote:
> We tried several other setups during the last days and got the following
> results. We used the "signverify.py" example from the pyme-0.6.2-tarball
> as a reference. We didn"t change anything but the "user" variable at the
> top of the script to an existing user in the keyring.

You could also temporary create another key with genkey.py to avoid
possibility that there's something wrong with the key itself.

> #1: ibook g4, ubuntu 5.04 stable.
>   I tried the prepackaged gpg, libgpgme, swig packages and built a pyme
> package from the tarball. Everything works as expected. Especially
> "result.signatures.summary" is != zero for a valid signature.
> #2: p4 laptop, debian unstable:
>   Everything from the distribution, pyme debian package from the
> sourceforge-website. "result.signatures.summary" is always 0, even for a
> valid signature.
> #3: p3, debian testing:
>   see #2.
> 
> We tried to rebuild everything from source (gpg 1.4.1, gpgme 1.0.2, pyme
> 0.6.2 and from cvs) on systems #1 and #2 but it didn"t change a thing.
> System #1 was always giving the right answers, the others didn"t. We
> even tried different swig-version but it still didn"t improve the
> situation. Do you have an idea what to try next? What kind of system do
> you use?

I have XP 1900+, debian unstable:
ii  libgpgme11     1.0.2-1        GPGME - GnuPG Made Easy
ii  gnupg          1.4.0-3        GNU privacy guard - a free PGP replacement

Do you have the same keyring on all those systems? If they are different and
you update 'user' in signverify.py for each of them I would recommend to
generate a new temporary key in each of them with genkey.py example. This way
you will be sure that key itself which also influences the summary does not
cause the difference.

BTW, you probably changed something else in signverify.py since in the original
form it does not print 'signatures.summary' :o) I've added its printing on my system
and it gives me back 3.

Next step I would do is to try eliminating pyme out of the picture by either writing
signverify in C using libgpgme11-dev directly or using t-verify.c from the tests/gpg
directory of the libgpgme11 source.

Cheers,
Igor

Re: [Pyme-help] Re: PyME: Segmentation Faults

[Robin B. <Ro...@fr...>]

Hello!

On Do, 2005-04-21 at 09:09 -0400, Igor Belyi wrote:
> My guess is that you either run into incompatibility between the versio=
n=20
> of GPGME PyMe was compiled with and the GPGME you are using at run-time=
=20
> or between GPGME and different version of GnuPG.
>=20
> PyMe 0.6.2 was compiled with GPGME 1.0.2 which comes from GnuPG 1.4.0=20
> but is supposed to be compatible upwards. I've run my tests so far only=
=20
> with libgpgme11 and gnupg as come prepackaged in unstable distribution=20
> of Debian.
>=20
We tried several other setups during the last days and got the following
results. We used the "signverify.py" example from the pyme-0.6.2-tarball
as a reference. We didn't change anything but the "user" variable at the
top of the script to an existing user in the keyring.

#1: ibook g4, ubuntu 5.04 stable.
  I tried the prepackaged gpg, libgpgme, swig packages and built a pyme
package from the tarball. Everything works as expected. Especially
"result.signatures.summary" is !=3D zero for a valid signature.
#2: p4 laptop, debian unstable:
  Everything from the distribution, pyme debian package from the
sourceforge-website. "result.signatures.summary" is always 0, even for a
valid signature.
#3: p3, debian testing:
  see #2.

We tried to rebuild everything from source (gpg 1.4.1, gpgme 1.0.2, pyme
0.6.2 and from cvs) on systems #1 and #2 but it didn't change a thing.
System #1 was always giving the right answers, the others didn't. We
even tried different swig-version but it still didn't improve the
situation. Do you have an idea what to try next? What kind of system do
you use?

Best regards,
Robin
--=20
Robin Brandt

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

7150 C3F9 F126 9BDE 5526  95D2 3C6D 40C9 BE2F 0AF6

B=C3=BCcher kaufen und Freie Software f=C3=B6rdern | http://bookzilla.de/

Re: [Pyme-help] Re: PyME: Segmentation Faults

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

Stefan Neumann wrote:

>OK, the fingerprint, i get as well.
>Like I wrote you I have Segmentation Faults with:
>
>result.signatures.next
>result.signatures.exp_timestamp
>result.signatures.validity_reason
>result.signatures.validity
>  
>
I've printed these fields as well without any segmentation faults.

>Precompiled debian package 0.6.2
>[..]
>  
>
>>If you use precompiled version - what version of PyMe and GnuPG do you use?
>>    
>>
>Python 2.3
>Pyme 0.6.2
>GnuPG: self build debian Package 1.4.1 with a small patch (doesn't
>change the working behaviour, just debug)
>  
>
My guess is that you either run into incompatibility between the version 
of GPGME PyMe was compiled with and the GPGME you are using at run-time 
or between GPGME and different version of GnuPG.

PyMe 0.6.2 was compiled with GPGME 1.0.2 which comes from GnuPG 1.4.0 
but is supposed to be compatible upwards. I've run my tests so far only 
with libgpgme11 and gnupg as come prepackaged in unstable distribution 
of Debian.

>So, thanks for your help, I will test it on a diffrent machine.
>  
>
Does this different machine has prepackaged GnuPG 1.4.0? :o)

Cheers,
Igor