Bug 2076 - having worked 2 times properly CLAWS ceased to decrypt incoming PGP mails -displays base64 instead - sucks completely
Summary: having worked 2 times properly CLAWS ceased to decrypt incoming PGP mails -di...
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail (Windows)
Classification: Unclassified
Component: default (show other bugs)
Version: 3.7.2
Hardware: PC Windows 2000
: P3 normal
Assignee: users
URL:
: 2155 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-12-13 12:12 CET by bug.z.botterbloem900
Modified: 2012-11-15 11:02 CET (History)
2 users (show)

See Also:


Attachments
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 (32.22 KB, image/png)
2009-12-13 12:16 CET, bug.z.botterbloem900
Details
Suggested patch fixing base64 decode (3.21 KB, patch)
2010-07-30 18:26 CEST, Yotam Medini
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description bug.z.botterbloem900 2009-12-13 12:12:24 CET
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 
Comment 1 bug.z.botterbloem900 2009-12-13 12:16:15 CET
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
Comment 2 Paul 2009-12-13 12:19:46 CET
looks like a broken message to me
Comment 3 bug.z.botterbloem900 2009-12-13 12:34:36 CET
message cannot be broken because The Same Backend gpg2.exe is able to decode it properly!
Comment 4 Paul 2009-12-13 12:57:22 CET
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.
Comment 5 Paul 2009-12-13 13:01:57 CET
Maybe the bug is in GPA which, btw, is not Claws Mail's pgp backend - Claws does its gpg/pgp handling internally using libgpgme.
Comment 6 bug.z.botterbloem900 2009-12-13 13:54:35 CET
>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?
Comment 7 bug.z.botterbloem900 2009-12-13 14:00:12 CET
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
Comment 8 bug.z.botterbloem900 2009-12-13 14:08:01 CET
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 ... ;-)
Comment 9 users 2010-01-15 14:43:36 CET
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!
Comment 10 Paul 2010-03-29 19:38:38 CEST
*** Bug 2155 has been marked as a duplicate of this bug. ***
Comment 11 Jochen Sch 2010-03-30 09:23:50 CEST
Confirming that changes in 3.7.5 do not fix bug 2155. s/Mime-crypted messages still are base64-encoded twice.
Comment 12 Yotam Medini 2010-07-30 18:26:51 CEST
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.
Comment 13 Yotam Medini 2010-08-25 07:54:39 CEST
The discussion on the suggested patch moved to 
 http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2245
bug 2245.
Comment 14 Colin Leroy 2012-11-15 11:02:32 CET
bug #2245 is fixed so I suppose this one too :)