[sylpheed:31298] Re: PGP/MIME-signing breaks sig delimiter

Michael Schwendt mschwendt at gmail.com
Sat May 12 21:23:51 JST 2007


On 12/05/07, Godwin Stewart wrote:
>
> Well, in that case, you can apply this patch to 2.4.1 instead of the
> previous one I sent:

Taking out four lines is trivial, but reverts to the state before the
ChangeLog entry, which says that the strchompall change increases
compatibility with other MUAs. Which MUAs are that? Which MUAs, upon
trying to verify a PGP/MIME signature, alter the signed data in a way
that is not covered by RFC2015?

    Multipart/signed and multipart/encrypted are to be treated by agents
    as opaque, meaning that the data is not to be altered in any way.

Stripping off whitespace of the end of lines is in violation with that
guideline. I believe Sylpheed ought not try to work around broken
PGP/MIME implementation in other MUAs. Instead, it ought to follow
RFC2015 and be done.

    For this reason all data signed
    according to this protocol MUST be constrained to 7 bits (8- bit data
    should be encoded using either Quoted-Printable or Base64).

Contrary to that, I see that Sylpheed creates PGP/MIME signed
"text/plain, UTF-8, 8bit" message content instead of encoding it QP,
7bit. Try it by signing Unicode content.

So, the real fix looks more like the code that is disabled with "#if
0" below the strchompall call in compose.c. I hope that Hiroyuki can
enlighten us about the reason for the strchompall attempt. What was
the original problem?


More information about the Sylpheed mailing list