Re: [Evolution] gpg help

[Jeffrey Stedfast <fejj ximian com>]

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
> > > > > bugs?
> > [...]
> >
> > > 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
> with.

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 :\

Jeff

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