Re: [Evolution] gpg help

[Not Zed <notzed ximian com>]

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.

> 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.

> (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.

> > then, I guess it depends on what you expect from a signed message. 
>
> I'd expect it to verify whenever possible. Meaning: any tampering with
> the message body causing signatures invalid signatures is a bug (there
> *may* be some few broken MTAs , but mostly the problems come from the
> MUA). Don't know what else to expect from a signed msg.

Well read above :)

> All said - evo is still a pretty cool mailer. palmpilot integration is
> strongest bonus for me.
>
> cheers
> -- vbi
>
>
> -- 
> secure email with gpg            avbidder fortytwo ch: key id 0x92082481
>                                  avbidder acter ch:    key id 0x5E4B731F