Re: [Evolution] gpg help

On Mon, 2002-06-03 at 04:40, Not Zed wrote:
On Mon, 2002-06-03 at 18:21, Adrian 'Dagurashibanipal' von Bidder wrote:
On Sun, 2002-06-02 at 19:01, Not Zed wrote:
On Mon, 2002-06-03 at 05:16, Jeffrey Stedfast wrote:
There were some bugs in the 1.0.x PGP/MIME code, these should all be
fixed now in the development CVS. Perhaps you came accros one of these

I dunno about all, but some more have been fixed.  And only for
multipart/signed (i dont ever want to support inline pgp, its even more
broken).  However i ran some tests, and i could generate mails that

Damn. I missed the MIME bit in Jeffrey's post. But I can understand not
wanting to support inline pgp. Still annoying, though, as they are still
quite frequent. Perhaps better remove inline support altogether (per
default), making it an experimental feature instead? Having inline
signatures not validating half of the time makes pgp/gpg look very
unreliable, which it isn't in my experience (it works basically
everywhere except in evolution...)

Well, inline pgp suddenly stipulates that a text/plain part must be
treated the same way as an 8 bit or binary part.  As completely opaque
data.  We store data decoded in memory, and so this breaks this
requirement.  And we're not about to change it.

Not to mention that it seems PMail (or was it something like PGPMail? I
forget the name of the client) sends binary attachments as inline pgp
signed data as well - so it's not *just* text parts. This makes it an
even bigger PITA.

The most annyoing bug for me was that signed mails with attachments
would never verify. That fixed?

Well, I sent some multipart/signed parts that had attachments inside
them, and they worked.  So, you'll have to test.  It hasn't been tested
a lot, I (and jeff?) dont have a great deal of infrastructure to test

Right. I've tested a few variations of things that I knew to cause
problems before the changes, and they all passed after the patches went
in. I can't say it's 100% fool proof now, but we'll see I guess.

(It seems building from cvs is a bit too complicated, as some of the
debian ...-dev pkgs are not current enough (libgal). Do I have to
rebuild most gnome libraries? Hmmm. I'll just wait for evo 1.2 release,
I think...)

gal and gtkhtml are really parts of evolution as far as development
goes, you need to build them both from cvs as well if you are to have
any joy in the process ...

The multipart/signed rfc's are broken, they break valid assumptions you
if for example any mailer blows apart mime parts and stores them
decoded, which imho is a perfectly valid thing to want to do).  But

Hmmm. I'd agree that this may be a valid thing to do in the local cache.
But I strongly feel that the mailer changing the msg body stored in the
mail spool (or imap dir) without being told so is broken.

So, how do you then move a message to a system that supports different
character sets?  Should you just throw it away?  No, you translate the
character sets?  What about if a mail is sent in 7 bit format, but your
transport supports an 8 bit or binary format?  Or visa versa?  It is
entirely upto the transport to decide what transfer encoding methods it
uses to get the content to the other end.  Thats the entire purpose of
mime in the first place, it isn't just to view the message content, its
to get it there in a reasonable manner which it can decide.

It's unfortunate that the PGP/MIME specification authors forgot this :\


Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]