pyme-help — Help for PyMe users

[Pyme-help] help needed with verify and 0.5.0

[Carsten R. <car...@ga...>]

Hello,

sory for asking for help for this _very outdated_ version of pyme, but 
the system that has to be used does not allow any other version because 
of the underlying gpgme-lib.

I managed to en- and decrypt messages and sign as well but verifying 
does not work for me.

The problem is in the third parameter of op_verify which in the original 
gpgme-func is of type GpgmeSigStat and will take the summarized result 
of the verification (with 0.8.0 you can do that with op_verify_result() 
and then check the signatures yourself).
As far as I can see there is no equivalent to this GpgmeSigStat-type in 
pyme so I tried to set it to None or use an integer var but the latter 
resulted in a type error requesting a _p_GpgmeSigStat type for that 
variable while the first resulted in an error messoge 'Invalid value (3)'.

I tried as well using only op_verify_start and asking 
get_sig_ulong_attr(0, attr.SIG_SUMMARY, 0) afterwards but that does not 
lead to anything else but zero as return value.

So is 0.5.0 not able to verify signatures or am I too blind to see how 
that works?

Any help, hints etc. warmly appreciated.

Thanks in advance

Carsten Reimer

-- 
Carsten Reimer
Web Developer
car...@ga...
Phone +49.228.42150.73

Galileo Press GmbH
Rheinwerkallee 4 - 53227 Bonn - Germany
Phone +49.228.42150.0 (Zentrale) .77 (Fax)
http://www.galileo-press.de/

Managing Directors: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker
HRB 8363 Amtsgericht Bonn

Re: [Pyme-help] verifying signatures

[Bernhard R. <ber...@in...>]

On Sunday 14 September 2008 11:23, Jérémy Morel wrote:
> > On Friday 12 September 2008 12:26, Jérémy Morel wrote:
> >> I am developing a very simple bug tracking app
> >> (http://www.naphtaline.net )

> > btw, did you have a look at http://roundup.sourceforge.net/?
> > It seems very close to your goals, you would probably just need to
> > customize it, e.g. write a better template.
>
> Nope, I didn't. and although it does a lot more that what my project
> will ever do, I'd like to finish a project on my own (this would be
> the first project I take to its end).

If you do it for exercise, this is of course useful.
Note that in practice any project manager would consider switching
to roundup as soon as it is discovered, if there is the intention 
of keeping this running seriously.

> I chose OpenPGP because it is simple. The intended users for my app do
> not have a technical background, and are not interested in getting
> one. My motto is "keep thing really simple, because otherwise their
> won't be any user". I thought that the enigmail plugin was simple
> enough to be used by anybody in 5 minutes.

Establishing trust with OpenPGP is harder for users (on the average)
than with the hierarchical S/MIME (x509) procedures I think.
This is debatable of course and beside the point.

> >> What I would like to do is the following :
> >>  - store user's public key in a database
> >>  - call a function like verifySignature(msg, senders_email,
> >> senders_publickey) which would return True or False
> >
> > Hmm, how should verifySignature work in detail?
>
> No idea about that :) Let me be more precise here. I receive a signed
> mail from an user. At the highest level, I just want to know if the
> signature found in the message is coherent with the email address of
> the sender (extracted from the mail)

The details of the key used for the signature will have the user ids 
which contain the email addresses. So you can compare it with whatever you
found in the email. gpgme does _not_ help you with parsing the email.

> and the public key this very user 
> gave me (extracted from the database). 

You could save the key_id or fingerprint and compare this to the key_id or
fingerprint of the key that was used for signing.

(I do not know if there is a comparison function, probably loading both keys
into gpgme objects, they should just be the same. Clashes in fingerprints 
should not be there I guess.)

> > (Note that a direct email would usually not just verify, usually the
> > email
> > needs to be parsed, especially if it uses the PGP/MIME format (as it
> > should)).
>
> That is something I don't really understand : what should I give as an
> argument ? If not the whole mail, then the mail's body ? Or even less
> data ? I don't get what the parsed email is in that case.

gpgme needs the signed data or the data objects with signature and data.
This depends on the email "format" used,
check rfc3156.txt for OpenPGP and MIME.

> About the PGP/MIME. I guess using standard plugins, like enigmail or
> the one for mail.app, I can assume that it will always use PGP/MIME,
> can't I?

Some software still offers deprecated inline non-MIME PGP style messages.

> > According to the documentation above, this is only filled if "mail"
> > is a
> > normal (or cleartext) signature and successfully verified.
> > So you probably should check the result values (again look at
> > verifydetails.py).
>
> What do you wall a cleartext signature ?

Where signature is within the file (as with non-MIME deprecated inline PGP 
signed emails). Compare with the results of gpg2 --clearsign x.

> Thanks again for the answer, it pointed out a lot of things that are
> not clear in my head.

You are welcome, best of luck for your project,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Re: [Pyme-help] verifying signatures

[Jérémy M. <mor...@gm...>]

Hi

First of all, thanks for this extensive answer !

> Hi Jérémy,
>
> On Friday 12 September 2008 12:26, Jérémy Morel wrote:
>> I am developing a very simple bug tracking app (http://www.naphtaline.net
>> ) and currently in the process of a major upgrade. I'd like to allow
>> the users to use their mailbox to post comments, change tickets
>> properties and create/delete tickets. I did the mail processing part,
>
> btw, did you have a look at http://roundup.sourceforge.net/?
> It seems very close to your goals, you would probably just need to  
> customize
> it, e.g. write a better template.

Nope, I didn't. and although it does a lot more that what my project  
will ever do, I'd like to finish a project on my own (this would be  
the first project I take to its end).

>
>> but I now have a bigger issue : how can I be sure that the sender is
>> the one he says he is ? I decided to force users to use gnupg /
>> enigmail to sign their messages (no encryption needed).
>>
>> My problem is that I have a lot of projects in my app, each with  
>> their
>> set of users, and of course somebody can use the same address email  
>> to
>> subscribe to two or more different projects.
>
> Note that this a conceptual problem that you need to solve
> and it is independent of the implementation.
> (Which means you could also ask on gnupg-users or gnupg-devel  
> mailinglists
> and have a good chance of getting answers.)
>
> So you want to use OpenPGP signatures to verify that email commands  
> came from
> one specific user. Yes, this can work. Now you have to make sure  
> that the
> signature is valid and was made using the key of the user it claims  
> to be
> from.

I chose OpenPGP because it is simple. The intended users for my app do  
not have a technical background, and are not interested in getting  
one. My motto is "keep thing really simple, because otherwise their  
won't be any user". I thought that the enigmail plugin was simple  
enough to be used by anybody in 5 minutes.

>
>> I may be wrong, but that
>> aspect prevents me from using the gnupg's key manager where you have
>> only one key manager for the unix account : it would create bridges
>> between the projects.
>
> I can imagine you using some of gnupg's keymanagement feature, but  
> there are
> probabyl several ways.
>
>> What I would like to do is the following :
>>  - store user's public key in a database
>>  - call a function like verifySignature(msg, senders_email,
>> senders_publickey) which would return True or False
>
> Hmm, how should verifySignature work in detail?

No idea about that :) Let me be more precise here. I receive a signed  
mail from an user. At the highest level, I just want to know if the  
signature found in the message is coherent with the email address of  
the sender (extracted from the mail) and the public key this very user  
gave me (extracted from the database). This is what I want to do. The  
"how" is the question.

>
>
>> I am not familiar with the gpgme C lib, and my little attempts at
>> manipulating data do weird things.
>
> The key to understand pyme is to read the documentation of the C  
> gpgme library
> (e.g. by "info gpgme" on the command line or "info:gpgme" in KDE's  
> Konqueror)
> Next the examples are very interesting, see my verifydetails.py in  
> particular.

I tried to understand the basics with the examples (and particularly  
verifydetails.py) but it clearly isn't enough. C documentation, here I  
come...

>
>
>> Here is a snippet :
>>
>> from pyme import core
>
> You must do core.check_version(None) once before.
>
>> c = core.Context()
>
>
>> file = open('snihf.eml','r')
>> rawMail = file.read()
>> file.close()
>> mail = core.Data(string=rawMail)
>
> Opening the file is unnecessary, you could directly do
> mail = core.Data(file="snihf.eml')
>
> (Note that a direct email would usually not just verify, usually the  
> email
> needs to be parsed, especially if it uses the PGP/MIME format (as it  
> should)).

That is something I don't really understand : what should I give as an  
argument ? If not the whole mail, then the mail's body ? Or even less  
data ? I don't get what the parsed email is in that case.

About the PGP/MIME. I guess using standard plugins, like enigmail or  
the one for mail.app, I can assume that it will always use PGP/MIME,  
can't I?

>
>
>> plain = core.Data()
>>
>> c.op_verify(mail, None, plain)
>
> info gpgme says:
> 7.6.2 Verify
> -- Function: gpgme_error_t gpgme_op_verify (gpgme_ctx_t CTX,
>          gpgme_data_t SIG, gpgme_data_t SIGNED_TEXT,
>          gpgme_data_t PLAIN)
>     The function `gpgme_op_verify' verifies that the signature in the
>     data object SIG is a valid signature.  If SIG is a detached
>     signature, then the signed text should be provided in SIGNED_TEXT
>     and PLAIN should be a null pointer.  Otherwise, if SIG is a normal
>     (or cleartext) signature, SIGNED_TEXT should be a null pointer and
>     PLAIN should be a writable data object that will contain the
>     plaintext after successful verification.
>
>     The results of the individual signature verifications can be
>     retrieved with `gpgme_op_verify_result'.
>
>     The function returns the error code `GPG_ERR_NO_ERROR' if the
>     operation could be completed successfully, `GPG_ERR_INV_VALUE' if
>     CTX, SIG or PLAIN is not a valid pointer, `GPG_ERR_NO_DATA' if SIG
>     does not contain any data to verify, and passes through any errors
>     that are reported by the crypto engine support routines.
>
>> result = c.op_verify_result()
>> print "mail : "
>> print mail.read()
>> print "plain : "
>> print plain.read()
>>
>> If I print mail.read() before the op_verify, I get the mail. If I do
>> it after, it is empty.
>
> Sound like correct behaviour, as the buffer was read until the end.
> You could try to seek() back to the the beginning.
>
>> But so is plain.read() ! rawMail is juste a
>> signed mail a friend sent me (his public key is not in my gnupg key
>> manager though)
>
> According to the documentation above, this is only filled if "mail"  
> is a
> normal (or cleartext) signature and successfully verified.
> So you probably should check the result values (again look at
> verifydetails.py).

What do you wall a cleartext signature ?

> To solve your problem I would compare the key that was used for the  
> signature
> with the key that you had saved for the user. (Maybe comparing key  
> ids or
> finderprints is enough security for you, would makes it a bit easier.)

I'll look into it. But since I still have to read doc and learn how  
the whole thing works, doing it the proper way shouldn't be much more  
difficult :)

Thanks again for the answer, it pointed out a lot of things that are  
not clear in my head.

Jeremy

Re: [Pyme-help] verifying signatures

[Bernhard R. <ber...@in...>]

Hi Jérémy,

On Friday 12 September 2008 12:26, Jérémy Morel wrote:
> I am developing a very simple bug tracking app (http://www.naphtaline.net
> ) and currently in the process of a major upgrade. I'd like to allow
> the users to use their mailbox to post comments, change tickets
> properties and create/delete tickets. I did the mail processing part,

btw, did you have a look at http://roundup.sourceforge.net/?
It seems very close to your goals, you would probably just need to customize 
it, e.g. write a better template.

> but I now have a bigger issue : how can I be sure that the sender is
> the one he says he is ? I decided to force users to use gnupg /
> enigmail to sign their messages (no encryption needed).
>
> My problem is that I have a lot of projects in my app, each with their
> set of users, and of course somebody can use the same address email to
> subscribe to two or more different projects. 

Note that this a conceptual problem that you need to solve
and it is independent of the implementation.
(Which means you could also ask on gnupg-users or gnupg-devel mailinglists
and have a good chance of getting answers.)

So you want to use OpenPGP signatures to verify that email commands came from 
one specific user. Yes, this can work. Now you have to make sure that the
signature is valid and was made using the key of the user it claims to be 
from.

> I may be wrong, but that 
> aspect prevents me from using the gnupg's key manager where you have
> only one key manager for the unix account : it would create bridges
> between the projects.

I can imagine you using some of gnupg's keymanagement feature, but there are 
probabyl several ways.

> What I would like to do is the following :
>   - store user's public key in a database
>   - call a function like verifySignature(msg, senders_email,
> senders_publickey) which would return True or False

Hmm, how should verifySignature work in detail?

> I am not familiar with the gpgme C lib, and my little attempts at
> manipulating data do weird things. 

The key to understand pyme is to read the documentation of the C gpgme library
(e.g. by "info gpgme" on the command line or "info:gpgme" in KDE's Konqueror)
Next the examples are very interesting, see my verifydetails.py in particular.

> Here is a snippet : 
>
> from pyme import core

You must do core.check_version(None) once before.

> c = core.Context()


> file = open('snihf.eml','r')
> rawMail = file.read()
> file.close()
> mail = core.Data(string=rawMail)

Opening the file is unnecessary, you could directly do 
 mail = core.Data(file="snihf.eml')

(Note that a direct email would usually not just verify, usually the email 
needs to be parsed, especially if it uses the PGP/MIME format (as it should)).

> plain = core.Data()
>
> c.op_verify(mail, None, plain)

info gpgme says:
7.6.2 Verify
 -- Function: gpgme_error_t gpgme_op_verify (gpgme_ctx_t CTX,
          gpgme_data_t SIG, gpgme_data_t SIGNED_TEXT,
          gpgme_data_t PLAIN)
     The function `gpgme_op_verify' verifies that the signature in the
     data object SIG is a valid signature.  If SIG is a detached
     signature, then the signed text should be provided in SIGNED_TEXT
     and PLAIN should be a null pointer.  Otherwise, if SIG is a normal
     (or cleartext) signature, SIGNED_TEXT should be a null pointer and
     PLAIN should be a writable data object that will contain the
     plaintext after successful verification.

     The results of the individual signature verifications can be
     retrieved with `gpgme_op_verify_result'.

     The function returns the error code `GPG_ERR_NO_ERROR' if the
     operation could be completed successfully, `GPG_ERR_INV_VALUE' if
     CTX, SIG or PLAIN is not a valid pointer, `GPG_ERR_NO_DATA' if SIG
     does not contain any data to verify, and passes through any errors
     that are reported by the crypto engine support routines.

> result = c.op_verify_result()
> print "mail : "
> print mail.read()
> print "plain : "
> print plain.read()
>
> If I print mail.read() before the op_verify, I get the mail. If I do
> it after, it is empty.

Sound like correct behaviour, as the buffer was read until the end.
You could try to seek() back to the the beginning.

> But so is plain.read() ! rawMail is juste a 
> signed mail a friend sent me (his public key is not in my gnupg key
> manager though)

According to the documentation above, this is only filled if "mail" is a 
normal (or cleartext) signature and successfully verified.
So you probably should check the result values (again look at 
verifydetails.py).

To solve your problem I would compare the key that was used for the signature 
with the key that you had saved for the user. (Maybe comparing key ids or 
finderprints is enough security for you, would makes it a bit easier.) 


Best of luck,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

[Pyme-help] verifying signatures

[Jérémy M. <mor...@gm...>]

Hi all !

I am developing a very simple bug tracking app (http://www.naphtaline.net 
) and currently in the process of a major upgrade. I'd like to allow  
the users to use their mailbox to post comments, change tickets  
properties and create/delete tickets. I did the mail processing part,  
but I now have a bigger issue : how can I be sure that the sender is  
the one he says he is ? I decided to force users to use gnupg /  
enigmail to sign their messages (no encryption needed).

My problem is that I have a lot of projects in my app, each with their  
set of users, and of course somebody can use the same address email to  
subscribe to two or more different projects. I may be wrong, but that  
aspect prevents me from using the gnupg's key manager where you have  
only one key manager for the unix account : it would create bridges  
between the projects.

What I would like to do is the following :
  - store user's public key in a database
  - call a function like verifySignature(msg, senders_email,  
senders_publickey) which would return True or False

I am not familiar with the gpgme C lib, and my little attempts at  
manipulating data do weird things. Here is a snippet :

from pyme import core

c = core.Context()

file = open('snihf.eml','r')
rawMail = file.read()
file.close()
mail = core.Data(string=rawMail)
plain = core.Data()

c.op_verify(mail, None, plain)
result = c.op_verify_result()
print "mail : "
print mail.read()
print "plain : "
print plain.read()

If I print mail.read() before the op_verify, I get the mail. If I do  
it after, it is empty. But so is plain.read() ! rawMail is juste a  
signed mail a friend sent me (his public key is not in my gnupg key  
manager though)

Could someone put me on tracks ? I'm a little lost here, and the  
python documentation does not help much.

Thanks in advance,

Jeremy

Re: [Pyme-help] contants -> constant names? for info

[Bernhard R. <ber...@in...>]

Igor,

On Sunday 17 August 2008 06:51, Igor Belyi wrote:
> That's an interesting idea, but I can't think of a python friendly way
> to implement it.
>
> Constants are basically 'integers' which could have conflicting values
> from different components. So, whatever
> mechanism is chosen to convert from an integer to a string should be
> component specific.

yes, it should be component specific.

> Another approach would be to make constants into 'objects' and then
> convert them to integers when they
> are passed to gpgme and have __str__() method which prints their name
> instead of their value but I think
> it's overkill for just an easier 'verbose' capability.
>
> Let me know what implementation exactly you have in mind.

I believe just a reverse dictionary should be created when 
creating the constants. The problem is that the original names
aim to be unique values in C, and the way it is done now, the strings
are not unique anymore in a __dict__ or dir(constants.validity).

constants.validity.table(uid.validity) might just give me the string.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Re: [Pyme-help] contants -> constant names? for info

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

Bernhard,

That's an interesting idea, but I can't think of a python friendly way 
to implement it.

Constants are basically 'integers' which could have conflicting values 
from different components. So, whatever
mechanism is chosen to convert from an integer to a string should be 
component specific.

Another approach would be to make constants into 'objects' and then 
convert them to integers when they
are passed to gpgme and have __str__() method which prints their name 
instead of their value but I think
it's overkill for just an easier 'verbose' capability.

Let me know what implementation exactly you have in mind.

Thanks,
Igor

Bernhard Reiter wrote:
> Hi Igor,
> I am starting to wonder if it would be practical to have a conversion function
> that will return the name of the constant from its value.
>
> When trying to interpret key.owner_trust or uid.validity, e.g. as in
>
>  key = c.get_key(keyfpr, False)
>  print "got key: ", key.subkeys[0].fpr, "owner_trust:", key.owner_trust
>  for uid in key.uids:
>         print uid.uid, "validity:", uid.validity
>
> from pyme.constants import validity
> gives me the constants, but from there it is difficult to contract
> their name. I could use the information from
>  dir(validity)
> ['FULL', 'MARGINAL', 'NEVER', 'ULTIMATE', 'UNDEFINED', 'UNKNOWN', 
> '__builtins__', '__doc__', '__file__', '__name__', 'util']
>
> but this would not be conclusive as there could be more integers in there.
> So in the end I would need to make my own list of the six values, which is
> not helpful. Why not have process_constants() create a sole table as well?
>
> I think there are quite a few use cases for this.
> Especially when trying to print extra information about what has happened,
> this is in the debug case, but also in the general "verbose" information case.
>
> Best,
> Bernhard
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pyme-help mailing list
> Pym...@li...
> https://lists.sourceforge.net/lists/listinfo/pyme-help
>   

Re: [Pyme-help] Problem with decrypting on win32 when private key has a pass phrase

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

Tony,

Thanks. I found a win32 machine and I can recreate the problem. In 
short, the problem happens after return from pyme into gpgme which means 
the problem is somewhere in the way pyme is built compared to gpgme. 
Originally, I thought just adding __stdcall to pyme routing would help 
but it didn't. I'm still investigating. I'll keep you posted.

Cheers,
Igor

Tony Caduto wrote:
> Igor,
>
> I can test things on win32 if you would like, just let me know.
>
> thanks,
>
> Tony
>
>
> On Mon, Aug 11, 2008 at 12:16 AM, Igor Belyi 
> <be...@us... <mailto:be...@us...>> wrote:
>
>     Anthony,
>
>     Thanks for reporting the problem. I'm sorry, for the delay - I had
>     some troubles with reading SF mail.
>
>     I don't have a Windows machine handy at the moment, but I'll try
>     to look at your problem as soon as I can. I noticed some strange
>     behavior with passphrase callbacks on Linux as well. I'll try to
>     reproduce the problem with pure gpgme to make sure that the
>     problem is in python wrapper and not in the core library.
>
>     I'll keep you posted.
>     Cheers,
>     Igor
>
>

[Pyme-help] contants -> constant names? for info

[Bernhard R. <ber...@in...>]

Hi Igor,
I am starting to wonder if it would be practical to have a conversion function
that will return the name of the constant from its value.

When trying to interpret key.owner_trust or uid.validity, e.g. as in

 key = c.get_key(keyfpr, False)
 print "got key: ", key.subkeys[0].fpr, "owner_trust:", key.owner_trust
 for uid in key.uids:
        print uid.uid, "validity:", uid.validity

from pyme.constants import validity
gives me the constants, but from there it is difficult to contract
their name. I could use the information from
 dir(validity)
['FULL', 'MARGINAL', 'NEVER', 'ULTIMATE', 'UNDEFINED', 'UNKNOWN', 
'__builtins__', '__doc__', '__file__', '__name__', 'util']

but this would not be conclusive as there could be more integers in there.
So in the end I would need to make my own list of the six values, which is
not helpful. Why not have process_constants() create a sole table as well?

I think there are quite a few use cases for this.
Especially when trying to print extra information about what has happened,
this is in the debug case, but also in the general "verbose" information case.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Re: [Pyme-help] Problem with decrypting on win32 when private key has a pass phrase

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

Anthony,

Thanks for reporting the problem. I'm sorry, for the delay - I had some 
troubles with reading SF mail.

I don't have a Windows machine handy at the moment, but I'll try to look 
at your problem as soon as I can. I noticed some strange behavior with 
passphrase callbacks on Linux as well. I'll try to reproduce the problem 
with pure gpgme to make sure that the problem is in python wrapper and 
not in the core library.

I'll keep you posted.
Cheers,
Igor

Tony Caduto wrote:
> Hi,
> The latest version of pyme seems to have a issue with decrypting on 
> windows and possibly linux when the private key has a pass phrase.
>
> When the key has a pass phrase it calls the call back, but then hangs 
> forever and the python instance has to be killed.
>
> The callback gets called and the 3 args get printed to the console 
> fine, then it hangs, but only when the key has a pass phrase.
>
> According to the gpgme doc you are supposed to write the password to a 
> file descriptor, but in all the examples the call back was done like 
> below.
>
> For all I know I could be doing something wrong, but it feels like a 
> bug to me.  Other users have also reported the same issue, please see 
> here:
> http://www.codeguru.com/forum/showthread.php?p=1743350
>
> def Callback(x, y, z):
>        """ Callback to give password """
>        print x
>        print y
>        print z
>        return "mypassword\n"
>
> print "gpgme version:", core.check_version(None)
> #File to be decrypted using a private key
> file_in = core.Data(file="c:\\my_enc_file.pgp")
> data_out = core.Data()
> #File we will write the encrypted data to
> # Initialize our pgp context.
> c = core.Context()
> c.set_armor(True)
>
>
> #this is needed if the private key has a passphrase, but it does not 
> seem to work on win32
> c.set_passphrase_cb(Callback)
>
> # Do the decryption.
> try:
>    c.op_decrypt(file_in, data_out)   #<------Hangs here when key has a 
> pass phrase
>    data_out.seek(0,0)
>    file_out = open("c:\\mydecrypted_file.dat","wb")
>    file_out.write(data_out.read())
>    file_out.close()
> except errors.GPGMEError, ex:
>    print ex.getstring()
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pyme-help mailing list
> Pym...@li...
> https://lists.sourceforge.net/lists/listinfo/pyme-help
>   

[Pyme-help] Problem with decrypting on win32 when private key has a pass phrase

[Tony C. <ton...@gm...>]

Hi,
The latest version of pyme seems to have a issue with decrypting on windows
and possibly linux when the private key has a pass phrase.

When the key has a pass phrase it calls the call back, but then hangs
forever and the python instance has to be killed.

The callback gets called and the 3 args get printed to the console fine,
then it hangs, but only when the key has a pass phrase.

According to the gpgme doc you are supposed to write the password to a file
descriptor, but in all the examples the call back was done like below.

For all I know I could be doing something wrong, but it feels like a bug to
me.  Other users have also reported the same issue, please see here:
http://www.codeguru.com/forum/showthread.php?p=1743350

def Callback(x, y, z):
       """ Callback to give password """
       print x
       print y
       print z
       return "mypassword\n"

print "gpgme version:", core.check_version(None)
#File to be decrypted using a private key
file_in = core.Data(file="c:\\my_enc_file.pgp")
data_out = core.Data()
#File we will write the encrypted data to
# Initialize our pgp context.
c = core.Context()
c.set_armor(True)


#this is needed if the private key has a passphrase, but it does not seem to
work on win32
c.set_passphrase_cb(Callback)

# Do the decryption.
try:
   c.op_decrypt(file_in, data_out)   #<------Hangs here when key has a pass
phrase
   data_out.seek(0,0)
   file_out = open("c:\\mydecrypted_file.dat","wb")
   file_out.write(data_out.read())
   file_out.close()
except errors.GPGMEError, ex:
   print ex.getstring()

[Pyme-help] New version of examples/verifydetails.py

[Bernhard R. <ber...@in...>]

Folks,
attaches a new version of verifydetails, which actually prints
one more detail and can deal with detached signatures. :)

Bernhard

-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Re: [Pyme-help] doing symmetric key encryption

[Bernhard R. <ber...@in...>]

Verbal,

On Tuesday 01 July 2008 23:34, verbal wrote:
> i'm trying to do symmetric key encryption with AES. i've tried pygpgme
> but with no luck. i was hoping you could help. the gpg equivalent
> commands i'm trying to replicate is:
>
> gpg --symmetric --cipher-algo AES256 --compress-algo BZIP2

I am not sure that gpgme provides an interface for symmetric encryption.
(Looking at the documentation and the code of gpgme 1.1.6 I cannot find it.)

My suggestion is to ask at gnupg-users@ or so if gpgme can do this.
If it can do it, then pyme would also be able to do it.

Bernhard


-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Re: [Pyme-help] pyme-0.8.0 announcement.

[Bernhard R. <ber...@in...>]

Igor,

On Monday 31 March 2008 00:54, Igor Belyi wrote:
> PyMe 0.8.0 is released. The major reason for going to 0.8.0 is an
> incompatible change in API.

thanks for the change. 
I have attached an updated version of testCMSgetkey.py
which used the new API.

Note for the tarball I suggest to move Changelog to OLD.Changelog
or so and add a NEWS file with the Release notes.
When using the tarball there is no information about how
the API has changed and why.

BTW, I could build stuff with Debian Etch, using libgpgme 1.1.6.


> Release Note:
>
> Bug fixes and small API changes release.

> Special thanks for this release goes to Bernhard Reiter
> for excellent suggestions on how to make PyMe even more
> python friendly.

Thanks for maintaining pyme. :)
Bernhard

-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

[Pyme-help] doing symmetric key encryption

[verbal <ve...@gm...>]

i'm trying to do symmetric key encryption with AES. i've tried pygpgme  
but with no luck. i was hoping you could help. the gpg equivalent  
commands i'm trying to replicate is:

gpg --symmetric --cipher-algo AES256 --compress-algo BZIP2

thanks,

verbal

[Pyme-help] pyme-0.8.0 announcement.

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

PyMe 0.8.0 is released. The major reason for going to 0.8.0 is an 
incompatible change in API.

Release Note:

Bug fixes and small API changes release.

The major change in this release is that all GPGME
structures containing field 'next' are now return as
python's list from function calls or when they are
accessed as member fields of another structure. If
such structure is an expected input parameter to a
call it should be passed as a normal object.

Another new feature - addition of Windows binary
install. It is build specifically to work with gpg4win
installation of GnuPG.

Special thanks for this release goes to Bernhard Reiter
for excellent suggestions on how to make PyMe even more
python friendly.

Cheers,
PyMe maintainer

Re: [Pyme-help] Segmentation fault in python-pyme

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

Alex Roper wrote:
> Using python-pyme 0.7.0-3build1 (the current version in Gutsy)
>
> Counterexample attached. I know this may be buggy code on part, but then it 
> should throw a Python exception, not cause gpgme to segfault.
>
> I'm aware that this is more likely a gpgme bug, but wanted to run it by you 
> first on the offchance that it's pyme related.
>   
This _is_ pyme bug. It was fixed in CVS two years ago. I've attached 
patch created against version 0.7.0 fixing the problem.

Cheers,
Igor

Re: [Pyme-help] pyme review

[Bernhard R. <ber...@in...>]

Hi Igor,

On Sunday 09 March 2008 20:11, Igor Belyi wrote:
> Bernhard Reiter wrote:
> > I am attaching this and another script which are Free Software.
> > Feel free to include it in the examples or somewhere else.
>
> I've added verifydetails.py to the list of examples. Thanks! 

Wonderful.

> The testCMSgetkey.py fits more for the test suite which pyme currently
> doesn't have.

I disagree as I believe it is an example how to fetch a key for S/MIME
(aka CMS Cryptographic Message Store or so) not really a "test". 
You might want to rename the script if you like to.

> > a) the use of check_version() is mandatory according to the gpgme
> > documentation. (See section 2.6 Library Version Check).
> > Your example applications fail to do it. This is a serious problem in my
> > view.
>
> Yes, according to that section it's important to call check_version()
> before anything else and I'd guess best to do it in the main thread as
> well. In short, I don't see how pyme could do that for applications. As
> a result, I just added it to all examples.

I believe this is good. I also thought about doing it in the pyme wrapper code 
but could not really judge the implications of threading.

> > b) Some documentation links in the Debian package's html files just lead
> > nowhere. A nice to have thing.
>
> Do you mean the links in the page heads pointing to the source file?
> That's the only ones I see leading to nowhere. 

I think so. (Without rechecking right now.)

> I'll fix them on the SF 
> page but in Debian package it will be a bit trickier. PY files are
> installed in a location specific to each python version and it means
> that documentation package would need to be python version specific as
> well - even when it's the same due to the PyMe version being the same. I
> may need to look if anybody else use pydoc to generate documentation and
> if they have any good solution to this problem.

At least it is a problem as it really looks nasty to somebody who just tries 
to browse the presumed "nice" documentation. :)
You probably should ask on Debian's lists to see how they propose to solve 
this.

> > c) It would be much more pythonic to use named parameter with default
> > values for functions. It just feels wrong at places to write
> >
> >   from pyme import core
> >   print "gpgme version:", core.check_version(None)
> > where core.check_version() should just do the job.
> > There are quite a few places where this would make the wrapper more
> > usable, because the using code will we more python-style.
>
> Yes, it will be more pythonic but then the wrapper will need to become
> aware what default value each function expects. This may make the
> wrapper a bit more complicated than I'd like it to be. The main idea is
> that the wrapper should be flexible to the changes in the gpgme APIs and
> having it as less aware of each function details as possible is one of
> the way to do it.

See, here is one point where SWIG makes it less pythonic (as I have feared in 
past correspondence). Their ought to be a way - as how it currently is, looks  
really ugly in Python. But yes, I prefer a maintained good working wrapper 
over an unmaintained one. Note that the interfaces of gpgme should be quite 
stable. In case they really change the interfaces, you would need to check 
the pyme wrapper anyway. So in total I guess it would be worth the change, 
but my SWIG experience is too far ago that I could say if this is easy.

> > d) In many places the return values really should be sequence, maybe
> > lists or tuples. Currently somebody really must follow the linked pointer
> > list in a way like:
> >      engine = core.get_engine_info()
> >      while (engine):
> >         print engine.file_name, engine.version
> >         engine = engine.next
> >
> > where someone would like to write:
> > 	for engine in core.get_engine_info():
> > 		print engine.file_name, engine.version
> >
> > looks more pythonic to me. :)
>
> Yes, returning an iterator object for types containing 'next' field is
> very good idea! Unfortunately, this will also break compatibility of the
> interface. I'm looking into doing it now but it will force me to move to
> version 0.8.0 as well. 

I agree it breaks the interface, but for good!

> If anyone reading this list think I should stay 
> the course instead - speak now!

Personally I believe this is an improvement.


> > Hopefully my remarks are useful!
>
> They are extremely useful! Thanks for your help.

You are welcome! Thanks again for writing this useful pyme!

> P.S. I removed gnupg-devel list from the Cc: since this discussion is
> completely python and pyme specific now. If you think they may benefit
> from it, feel free to add it back.

Fine with me.

Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Re: [Pyme-help] pyme review

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

Hi Bernhard,

Bernhard Reiter wrote:
> I am attaching this and another script which are Free Software.
> Feel free to include it in the examples or somewhere else.
>   
I've added verifydetails.py to the list of examples. Thanks! The 
testCMSgetkey.py fits more for the test suite which pyme currently 
doesn't have.

> Yes, the pygpa is quite impressive. 
> It lacks a bit of icons, though and some of the funcationality... :)
>   
Since pygpa.py is an example for pyme it only provides the functionality 
implemented in gpa with gpgme. There's some pieces of code in gpa which 
use gpg directly due to the fact that it's impossible to do them using 
gpgme -  like importing secret keys, for example. As for icons... I 
didn't want to copy them and relying on the ones provided with gpa would 
make that example dependent on gpa.

> A few things that I have noticed.
>
> a) the use of check_version() is mandatory according to the gpgme 
> documentation. (See section 2.6 Library Version Check).
> Your example applications fail to do it. This is a serious problem in my view.
>   
Yes, according to that section it's important to call check_version() 
before anything else and I'd guess best to do it in the main thread as 
well. In short, I don't see how pyme could do that for applications. As 
a result, I just added it to all examples.

> b) Some documentation links in the Debian package's html files just lead 
> nowhere. A nice to have thing.
>   
Do you mean the links in the page heads pointing to the source file? 
That's the only ones I see leading to nowhere. I'll fix them on the SF 
page but in Debian package it will be a bit trickier. PY files are 
installed in a location specific to each python version and it means 
that documentation package would need to be python version specific as 
well - even when it's the same due to the PyMe version being the same. I 
may need to look if anybody else use pydoc to generate documentation and 
if they have any good solution to this problem.

> c) It would be much more pythonic to use named parameter with default values
> for functions. It just feels wrong at places to write
>
>   from pyme import core
>   print "gpgme version:", core.check_version(None)
> where core.check_version() should just do the job.
> There are quite a few places where this would make the wrapper more usable,
> because the using code will we more python-style.
>   
Yes, it will be more pythonic but then the wrapper will need to become 
aware what default value each function expects. This may make the 
wrapper a bit more complicated than I'd like it to be. The main idea is 
that the wrapper should be flexible to the changes in the gpgme APIs and 
having it as less aware of each function details as possible is one of 
the way to do it.

> d) In many places the return values really should be sequence, maybe lists or 
> tuples. Currently somebody really must follow the linked pointer list in a 
> way like:
>      engine = core.get_engine_info()
>      while (engine):
>         print engine.file_name, engine.version
>         engine = engine.next
>
> where someone would like to write:
> 	for engine in core.get_engine_info():
> 		print engine.file_name, engine.version
>
> looks more pythonic to me. :)
>   
Yes, returning an iterator object for types containing 'next' field is 
very good idea! Unfortunately, this will also break compatibility of the 
interface. I'm looking into doing it now but it will force me to move to 
version 0.8.0 as well. If anyone reading this list think I should stay 
the course instead - speak now!

> Hopefully my remarks are useful!
>   
They are extremely useful! Thanks for your help.

Cheers,
Igor

P.S. I removed gnupg-devel list from the Cc: since this discussion is 
completely python and pyme specific now. If you think they may benefit 
from it, feel free to add it back.

[Pyme-help] pyme review

[Bernhard R. <ber...@in...>]

Igor,

On Tuesday 08 January 2008 15:04, Igor Belyi wrote:
> > at some point in time we will give it a shot with pyme and then you
> > will get reports. ;)

congratulations on pyme!
I gave it a spin and found it to be a usable piece of software
and a capable gpgme wrapper!

I even used it to write a test script for a gpgme defect,
see https://bugs.g10code.com/gnupg/issue876.
I am attaching this and another script which are Free Software.
Feel free to include it in the examples or somewhere else.

> I'd recommend to start with examples provided with pyme. There's even
> some Glade based GUI ones if you like that sort of things. :)

Yes, the pygpa is quite impressive. 
It lacks a bit of icons, though and some of the funcationality... :)

> And as for the reports - Bring them on! ;)

A few things that I have noticed.

a) the use of check_version() is mandatory according to the gpgme 
documentation. (See section 2.6 Library Version Check).
Your example applications fail to do it. This is a serious problem in my view.

b) Some documentation links in the Debian package's html files just lead 
nowhere. A nice to have thing.

c) It would be much more pythonic to use named parameter with default values
for functions. It just feels wrong at places to write

  from pyme import core
  print "gpgme version:", core.check_version(None)
where core.check_version() should just do the job.
There are quite a few places where this would make the wrapper more usable,
because the using code will we more python-style.

d) In many places the return values really should be sequence, maybe lists or 
tuples. Currently somebody really must follow the linked pointer list in a 
way like:
     engine = core.get_engine_info()
     while (engine):
        print engine.file_name, engine.version
        engine = engine.next

where someone would like to write:
	for engine in core.get_engine_info():
		print engine.file_name, engine.version

looks more pythonic to me. :)

Thanks again for the nice library,
I even saw that roundup uses it in the latest versions.
Hopefully my remarks are useful!

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Re: [Pyme-help] Problem with building PyMe

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

Nima Dokoohaki wrote:
> My mistake, I think I gave you wrong info, I copy/pasted that from my 
> previous emails Igor,
> It has nothing to do with apache. I solved the problem of _apache, It 
> had to do with configurations.
> I moved the directive to main config and it seems ok now with apache 
> for me.
> unfortunately I get this error while installing , and during the 
> script run i get "no module named pyme"
>
> Well, I run the command " Python setup.py install " ;
> linux-station:/home/nima/pyme-0.7.0 # python setup.py install
> running install
> running build
> running build_py
> running build_ext
> building 'pyme._gpgme' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
> -Wstrict-prototypes -fPIC -I/home/nima/pyme-0.7.0 
> -I/usr/local/include/python2.5 -c gpgme_wrap.c -o 
> build/temp.linux-i686-2.5/gpgme_wrap.o -I/usr/local/include
> gcc: gpgme_wrap.c: No such file or directory
> gcc: no input files
> error: command 'gcc' failed with exit status 1
This error means that you didn't run SWIG on gpgme files first. The 
correct way would be to run 'make install' which makes all necessary 
build steps. If you want details you can look in the Makefile which 
controls what 'make' does but in short it preprocesses gpgme.h using a 
short python script and generates gpgme_wrap.c using swig before 
building the pyme module itself.

Hope it helps,
Igor

Re: [Pyme-help] Problem with building PyMe

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

Nima,

First, I think it's not a good reason to switch between Linux 
distributions just because you have such a small problem. I could only 
hope that you will find more of them latter on. ;-)

As for the problem itself, I'd like to know more regarding how did you 
do the build and in what environment since there's no dependency on 
apache in the pyme package whatsoever.

Looking though my Google query hits reveals that _apache is a module 
loaded by Apache when it runs. It sounds a little bit strange that you 
would get that during build of the pyme. What command you run (and 
where) to do the build? Are you sure you see the problem during build 
and not while running a script using it?

I'm also slightly surprised to see python2.5 to be in /usr/local/lib. 
I'm not quite familiar with openSUSE details but is it where the 
official install puts it or did you do installation of some packages on 
your own? If the latter - which of the Apache, mod_python, and Python2.5 
did you installed yourself? Did you verified that their installation was 
successful?

Cheers,
Igor

Nima wrote:
> Message body follows:
>
> Dear Igor,
>
> I have a project I want to setup and use and it is written
> in python and it has a lot of dependencies. I use apache
> Apache/2.2.4 with mod_python/3.3.1 using Python 2.5 on
> openSUSE linux 10.2.
> Unfortunately being a novice in python and linux both are
> bothering me;
>
> 1) I tried building PyMe-0.7.0 and I got this message:
>
>   File "server.py", line 37, in <module>
>     from mod_python import apache
>   File
> "/usr/local/lib/python2.5/site-packages/mod_python/apache.py",
> line 30, in <module>
>     import _apache
> ImportError: No module named _apache 
>   File "server.py", line 37, in <module>
>     from mod_python import apache
>   File
> "/usr/local/lib/python2.5/site-packages/mod_python/apache.py",
> line 30, in <module>
>     import _apache
> ImportError: No module named _apache
>
> I tried rebuilding SWIG and gpgme and no changes.
> What do you suggest me to do ? Do you think it has to do
> with the distribution of my linux ? Should I move to debian?
>
> It would be nice of you to help me on this matter, 
>
> Warmest regards,
> Nima
>   

Re: [Pyme-help] pyme question

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

I guess I do need to mention build dependencies in INSTALL file...

In short, yes, you need to have Python (2.2 at least), Gpgme (1.1.0 at 
least), and SWIG installed.

Igor

Imran Akbar wrote:
> Hi,
>    Are there any instructions on how to install pyme?  do I need to 
> install gpgme and swig first?
>
> thanks,
> Imran

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

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

Arnaud Fontaine wrote:
> Are you planning a new stable release of pyme soon which will include
> this patch ?
>   

Well.. I do plan 0.7.1 release "any minute now" for the last half an 
year. :-(

I want to figure out why do I still have problems with MinGW32 built 
PyMe on Windows.
The problems boils down to gpgme problems with talking to gnupg.exe and 
obstacted by
my inability to find the right time to "really" look at them. I guess I 
would try newly
released GnuPG 1.4.4 to see if it is fixed there... But as for "when" - 
that's the hard
question.

In short, I'd suggest to add this patch in a debian specific release to 
avoid its eviction from
the testing or to speed up the inclusion into one. :-)     The new 0.7.1 
release will have just
the Windows build and 2 (including this one) bug fixes which is not too 
much "value-add"
for Debian.

Cheers,
Igor

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

[Arnaud F. <ar...@an...>]

>>>>> "Igor" == Igor Belyi <be...@us...> writes:

    Igor> I've got it! Here's a slightly better patch which should not
    Igor> break back compatibility and does not use undocumented
    Igor> features. I'm making similar changes in CVS as well.

Hello Igor,

Are you  planning a new stable  release of pyme soon  which will include
this patch ?

Regards,
Arnaud Fontaine