GNOME Bugzilla – Bug 124905
move balsa to gpgme 0.4.3
Last modified: 2005-08-15 01:30:23 UTC
Below is a big patch (in bzip2 format, against the balsa-2-0 CVS of Oct. 18th, 2003) to migrate balsa to the gpgme 0.4.3 library and to introduce some tiny improvements to signature handling: * Completely move to libgpgme 0.4.3 and libgpg-error 0.5.0 (available from ftp://ftp.gnupg.org/gcrypt/alpha/gpgme and ftp://ftp.gnupg.org/gcrypt/alpha/libgpg-error, respectively) and remove all old (deprected) stuff. Note that gpgme 0.4.2 (and probabely older) has a tiny bug preventing signatures with a missing public key from being processed correctly (this is also the reason for the long delay for the patch...). Note that the configure option to enable gpgme now has the syntax --with-gpgme[=<gpgme configure script>] e.g. --with-gpgme=/opt/gpgme-0.4/bin/gpgme-config as gpgme now depends on libgpg-error. Furthermore, there are now two versions of the library, with and without pthread support. If balsa is built with threads, the libgpgme version with pthread support is selected automatically. I *hope* this resolves the threading issues found with gpgme on some platforms. YMMV... * Support for detecting S/MIME v. 3 (RFC 2633) messages/parts has been added. Note that balsa can not (yet?) handle (i.e. decrypt or verify) such messages; it just pops up a warning informing the user that it's not yet implemented. As soon as I figure out how I can add it (using GpgSM from the "Ägypten" project? Or GnuPG 1.9?), balsa *should* be able to do it, though. Stay tuned... * Signatures which could not be verified due to a missing public key now pop up a warning dialog (which can be disabled using the main config dialog). There is now a button to retreive the missing key in the signature part and in the context popup (RFC 3156 message) or below the message text (RFC 2440). * The result of retreiving a public key is checked using a timeout callback instead of an idle callback, thus consuming much less cpu time. * The signature status is printed in the "Message parts" tab for each signature. Patch details: ============== * libbalsa/rfc3156.[hc]: The meat of the patch... * libbalsa/send.c: changed some constants for clarity * src/balsa-message.c: changed method to determine if a message is signed/encrypted (see new function libbalsa_message-body-protection() from libbalsa/rfc3156.[hc]), change gui to import a key using gpg * src/main.c: paranoia check if gpg (and not only gpgsm) is available * src/print.c: changed some constants for clarity * src/sendmesg-window.c: ditto * configure.in: new test for gpgme, use thread-safe libgpgme if building balsa with threads
Created attachment 20775 [details] patch in bz2 format
Works great for me. Only problem : a compile error if PCACHE is not defined : on line 2065 of libbalsa/rfc3xxx.c (sorry I don't remember the exact names now), the arguments 2 and 3 or get_passphrase_real are interverted. I'll try to test it more.
Euh actually I ran into another problem : I have 2 keys for the same e-mail address (yes because I forgot the password for the first one ;-). And when I set sign/encode in my identity (I have only one), I tried to compose a message, then on sending I have been asked to choose between the two keys, what I did, then the password, validated and then it asked me once more to choose between the two keys TWICE (though I think it did not re-ask for the password). BTW if you know how to remove a key (please do not tell me I cannot if I have not set the revocation certficat ;-)
Below is a new patch which fixes the argument mixup for get_passphrase_real(). It's against yesterday's CVS, so it should also fix the relocation warnings. As for the key selection: Balsa asks for each mail address with a non-unique key separately. So if you send a signed and encrypted mail to yourself, it first asks for the from: (signing) and then for the to: (encryption) address. Note that since 0.4.3, gpgme uses different (sub-?) keys for signing and encryption, thus asking for the passphrase for signing and for encryption separately. If the cache is enabled, it will also be stored twice.
Created attachment 21632 [details] new (improved) patch
Again an improved patch (against the cvs of Nov 30, 2003): * detect if gpg is not available and disable crypto stuff in this case instead of aborting balsa; * move crypto stuff in balsa-message.c into separate functions to improve code readability.
Created attachment 21944 [details] new patch
The most recent patch is in balsa-2-0 branch.
Adding the PATCH keyword.
What about 2.1.x? Should I leave this report open or should there be a separate report for the main branch?
IMHO you can leave this open... I'll start working on a port to 2.1 when I have s/mime for 2.0 ready (I need that urgently)
The big patch below (bzip2 compressed) brings gpgm(me) support to the HEAD branch (reference: CVS of April 16th, 2004). You need at least gpgme 0.4.3 (recommended: 0.4.5) and gmime 2.1.3 (recommended: cvs released on or after after April 11th, 2004) to use it. The status is: * RFC 2440 (aka OpenPGP) is fully supported. If you observe hangs when when reading signed and/or encrypted messages, please try the cvs version of gmime (see above) first before reporting a bug, as it fixes a bug in stream processing which may cause such hangs. * RFC 3156 (aka PGP-Mime): sending signed and/or encrypted messages seems to work fine. When reading such messages, balsa may falsely report bad signatures (i.e. indicating messages being tampered with). The reason is a nasty gmime bug: gmime passes the part's contents verbatim to the crypto engine, but may re-arrange the headers (which are part of the protected contents) and/or omit double quotes from headers which are not strictly needed according to the RFC's. The simplest way to reproduce it is by creating a multipart message (i.e. a message with an attachment) with balsa 2.0, and send to yourself@localhost. Reading with balsa 2.0 should give a good, and with balsa 2.1 a bad signature. This is obviously an extremely bad situation, as it makes security completely unreliable and therefore (IMO) unusable. Jeff knows this problem, but didn't provide a fix yet. So if you hit this bug, *please* mail him (and not me)... * RFC 2633 (aka S/MIME): not yet supported. I have some ideas how it could be included gluelessly into gmime, though, so stay tuned... Please note that the passphrase cache ist not supported, as it needs OpenSSL, and it's yet unclear for me how the necessary initialisation of the library could be done in a way not interfering with imaps. IMO the cache should be regarded as depracted, as the next generation gpg (currently 1.9.7) which will be needed for S/MIME support anyway comes with a gpg-agent and thus provides system-wide passphrase reading (via pinentry) and caching in a much safer way (using unswappable memory). There are two smaller "todo's": At first, the update of the padlock icons in the index is done asynchronously and shows some delay between clicking an the message and the update. I guess I have to introduce a new signal to speed it up. But maybe someone has a better idea? Secondly, the OpenPGP signature status is now appended in italics to the text body, but *after* wrapping as the wrapping process seems to conflict (== segfaults) with the tag when added before. The result may just look ugly. Again, any hint is welcome. The "meat" of the patch is in three files (and the associated headers) in libbalsa: gmime-gpgme-context implements the crypto backend access, gmime-gpgme-signature implements the signature info provided by gpgme in a GObject way, and gmime-part-rfc2440 provides RFC 2440 extensions for GMimePart. I think I will use these files in a different project, so it might be a good idea to pack them in a different lib in the future for simplified maintenance. rfc3156.[hc] (still libbalsa) shrunk a lot, as it now merely provides the glue between (lib)balsa and gmime. identity.[hc] have been extended to enable pre-selection of the preferred crypto protocol (RFC 2440/3156 and maybe 2633 in the future). body.[hc], send.c, libbalsa.h, mailbox.c and message.[hc] were touched to use the new interfaces. padlock-keyhole.xpm is the icon for the passphrase dialog, and Makefile.am adds or excludes the crypto stuff from compilation according to the configuration. Note that I had to remove GTK_DISABLE_DEPRECATED from the defs as the identity stuff uses an option menu which is depracted with gtk+ 2.4/gnome 2.6. In src, the touched files are balsa-app.[hc], balsa-message.c, main-window.c, main.c, print.c and sendmsg-window.c, basically porting all improvements from 2.0 to 2.1. Furthermore configure.in and po/POTFILES.in have been touched. After applying the patch (using bzcat <file> | patch -p 1, as usual), you must run autogen.sh again. The configure option to use gpgme is (as with 2.0) --with-gpgme=<path of gpgme-config>. As always, I am yery interested in any comments and opinions about this!
Created attachment 26752 [details] [review] bzip2 compressed patch for HEAD branch
Just to clarify a confusion with the headers and the old (2003) discussion above: the last patch *is* actually for head/2.1...
Commited to CVS. Thanks!