Hello. in november 2009 i installed Claws 3.7.2cvs27 which was included in a GPG4WIN Package (i reinstalled it several times in the meantime.) i generated two keys for my own email addresses and installed one (1) of another person which is my email friend. (I did not generate additional "keyrings" or GPG.CONF Files because i dont want to develop a GPG / PGP System on my own accord. i simply used the GPA Gnu Privacy assistant instead). Now the problem is: 1.) Every incoming email from my email friend is displayed un-encoded, i cannot read anything. just "---- BEGIN PGP message ..." and lots of BASE64-encoded stuff is visible. i'd like to state that everything is installed correctly esp. "S/MIME" problem can be excluded. (Even Those 2 Emails Which could be displayed (encrypted) Initially, in Past, cannot be decrypted any more.) My email friend - the only sender of encrypted mails to me - is using thunderbird, and he is reporting that Thunderbird has changed his preferences from HTML to Plain text , but first he did a manual override to Html again. 2.) when copying this BASE64-stuff into Clipboard of GPA and trying to decode manually, it displays a dangerous red STOP-sign "Error in operation result: no valid UTF-8 at position XXX" where XXX varies depending from the actual message, XXX
Created attachment 781 [details] The Pop-up shown by the Claws PGP backend called GPA Gnu privacy assistant, when called manually with the base64 encoded text into Clipboard area
looks like a broken message to me
message cannot be broken because The Same Backend gpg2.exe is able to decode it properly!
If the msg is constructed like this, (which it apparently is): -----BEGIN PGP SIGNED MESSAGE----- [base64 encoded content] ...... then it is broken, because the "BEGIN PGP SIGNED MESSAGE" line is part of the message body and all of the message body should be base64 encoded.
Maybe the bug is in GPA which, btw, is not Claws Mail's pgp backend - Claws does its gpg/pgp handling internally using libgpgme.
>then it is broken, because the "BEGIN PGP SIGNED MESSAGE" line is part of the message body I think this is the usual encoding scheme for armored PGP messages. this should be irrelevant, because Claws shows this as body of mail, as OE does, and my mails sent to my email friend look the same way when decoding is off. Thunderbird is able to decode such messages too => the diagnosis "broken message" may not apply. Claws and GPG are installed together. ClawsMail.exe is in my D:\Programme\GNU\GnuPG folder amongst all other utilities like gpg, thus i assumed a close connection. Maybe i'm wrong with respect to this connection. If Claws relies on its own libraries , as you wrote, then why appears a GPA -look-alike dialog window which asks for my passphrase before sending emails?? to me, this fact illustrates a close connection or interprocess communication between Claws and GPA. And why is claws able to use the keys which i created / imported by means of GPA beforehand?
p.s.: >Maybe the bug is in GPA which.. this could be the case, too. If Claws and GPA use the same (static) libraries the same erroneous behaviour would be duplicated
P.p.s. if i omit the "---BEGIN " Header, GPA - as expected - pops up a dangerous red message box with this text: "clipboard does not contain properly encoded pgp message". so please dont tell me the reason were a broken message ... ;-)
Changes related to this bug have been committed. Please check latest CVS and update the bug accordingly. You can also get the patch from: http://www.colino.net/claws-mail/ 2010-01-15 [colin] 3.7.4cvs2 * src/privacy.c Decode mimeinfo before decrypting it. Probably fixes bug 2059 'gpgme >=1.1.8 not compatible with S/MIME encryption' and bug 2076 'having worked 2 times properly CLAWS ceased to decrypt incoming PGP mails -displays base64 instead - sucks completely' Let's hope complete suckage ends here!
*** Bug 2155 has been marked as a duplicate of this bug. ***
Confirming that changes in 3.7.5 do not fix bug 2155. s/Mime-crypted messages still are base64-encoded twice.
Created attachment 876 [details] Suggested patch fixing base64 decode In claws-mail-3.7.6, decoding base64 (attachment) in claws-mail has some bugs.a The attached patch fixes the problems at least for my use cases. The changes: + In base64_decoder_decode(...) * An 'inlen' parameter added. * Checking for padding character '=' changed. It is now also used as sufficient (though non-necessary) condition for end-of-input. * "Unrecognized" characters like 'null' or 'space' or silently ignored, and do not imply end-of-input. * Comments about saved tail of input were added. + In procmime_decode_content(...) [the ENC_BASE64 case] * The input chunks are read by fread(...) (instead of fgets(...)). This solves the problem of reading just one line at a time. Similar change should probably be applied to other cases (such as ENC_QUOTED_PRINTABLE, ENC_X_UUENCODE, default), but I did not have cases to test them with. * Check is added that the actual number of desired chars are read.
The discussion on the suggested patch moved to http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2245 bug 2245.
bug #2245 is fixed so I suppose this one too :)