Bad signature (was: Re: GPG support in Mahogany)

[Ingo Klöcker]

--Boundary-02=_yXG/9TNyWOhpHuu
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

[cc'ed back to gnupg-users ml]

On Saturday 14 December 2002 22:17, Jeffrey Stedfast wrote:
> On Friday 13 December 2002 04:38, Dave Barton wrote:
> > > When I asked the Ximian Evolution developers if there was a known
> > > problem with PGP/MIME in Evo 1.2 they responded:
> > >
> > > <Q>
> > > In Evolution 1.0.x, we did not treat signed parts as "opaque"
> > > because our MIME parser had been written to comply with previous
> > > MIME specifications which did not define such a type. It is, in
> > > our opinion, broken that rfc2015 requires signed parts to be
> > > treated as opaque because it is placing further restrictions
> > > which did not previously exist for MIME. This is an absolute
> > > no-no when extending standard protocols. Then, of course, the
> > > PGP/MIME authors broke things yet again when they released the
> > > newer rfc3156 specification which was not fully compatable with
> > > rfc2015.
> > >
> > > So, to answer your question: in Evolution 1.2, we have modified
> > > the parser to special-case multipart/signed so that we keep the
> > > raw data (this is what opaque means) so that when we go to verify
> > > the signature, we feed gpg the raw data as originally found in
> > > the mbox file.
> >
> > Hmm, either they didn't read RFC 3156 carefully enough or they did
> > omit an important detail. RFC 3156 says:
>
> <snide remark>
> Hmm, either Ingo didn't read Evolution's source code carefully enough
> or he just didn't read it all before making wild (and false)
> accusations. </snide remark>

Yes, I didn't read the source code at all. But I also didn't make any=20
wild accusations. I just compared what someone of the Evolution=20
developers replied to Dave with what is said in RFC 3156. As you can=20
read above the developer claimed that "the raw data as originally found=20
in the mbox file" is fed to gpg. This would not be correct since the=20
CRLF canonicalization is missing (or maybe you store all emails with=20
CRLF in the mbox file, but that would be very unusual on a Unix=20
system).

> This is the kind of thing that I do not particularly appreciate.

Well, I'm sorry that you misread my reply. And I'm glad that my=20
hypothesis was wrong and that Evolution now seems to be compatible with=20
KMail (after I fixed a bug in KMail).

> > "Upon receipt of a signed message, an application MUST:
> >
> >    (1)   Convert line endings to the canonical <CR><LF> sequence
> > before the signature can be verified.  This is necessary since the
> > local MTA may have converted to a local end of line convention.
>
> we do.

Good. But that's not what Dave was told.

> >    (2)   Pass both the signed data and its associated content
> > headers along with the OpenPGP signature to the signature
> > verification service."
>
> we do. Is there a reason you pasted this section of rfc3156? Or are
> you just trying to be a smart-ass?

I quoted this section because this section explains what a MUA has to do=20
to verify a OpenPGP/MIME signature. And as Evolution had problems with=20
verifying OpenPGP/MIME signed messages created by KMail I wanted to be=20
sure that the error is in KMail and not in Evolution.

This error stems from the fact that Evolution seems (another wild=20
accusation ?) to strip off trailing spaces before it passes the signed=20
stuff to gpg. Is this assumption correct? If not, then I'd like to know=20
why else Evolution had problems to verify some of my messages (which=20
contained trailing spaces) while now that KMail doesn't create any=20
trailing spaces anymore Evolution doesn't seem to have any problems=20
anymore.

> > Now I wonder whether the developers of Evolution forgot the
> > <CR><LF> canonicalization or whether they only forgot to tell you
> > about it.
>
> Uh... we did not forget about it. We do perform CRLF canonicalisation
> before passing it off to gpg. What makes you think that we don't? Is
> there any valid proof? If there is, I would like to see it. If there
> are situations in which our CRLF filter fails, I would like to know
> about it so that I may fix it.
>
> Please see
> evolution/camel/camel-multipart-signed.c:camel_multipart_signed_sign(
>) for proof that we did it right.

Thanks.

> > BTW, this message was created after applying a fix to KMail (now
> > KMail encodes trailing spaces correctly). Is the signature now
> > valid, Dave?
> >
> > Regards,
> > Ingo
>
> Ingo, next time you feel that Evolution is doing something
> incorrectly - please be a man and come to me with the problem so that
> I may look into it rather than you going off and spouting false
> accusations. No one appreciates this, especially when they work hard
> to make it fully compliant with all relavent specifications and
> otherwise do the best they can do.

Sorry, about that. We (the subscribers of the gnupg-users ml) just tried=20
to find out why some of the members of gnupg-users had problems=20
verifying the messages of other members. One reason turned out to be a=20
bug in KMail and I'm glad that I could fix it.

I didn't want to give anyone the impression that Evolution is doing=20
something wrong. I just noticed that what whoever told to Dave is not=20
in accordance with the specs. And therefore I wanted to be sure that=20
this person just didn't tell Dave the whole thing resp. that he omitted=20
telling him an important detail (that's what I meant by "or they did=20
omit an important detail"). My only fault is that I should have=20
probably cc'ed my message to the evolution-developers mailing list=20
(assuming that such a mailing list exists).

Regards,
Ingo


--Boundary-02=_yXG/9TNyWOhpHuu
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA9/GXyGnR+RTDgudgRAqSYAKDMIR6h9o8JbTpfiP2lyogbPbTNQQCfYQGx
4rogXezoPbqHje9ghzMKy6k=
=+Uxj
-----END PGP SIGNATURE-----

--Boundary-02=_yXG/9TNyWOhpHuu--