Re: [gmime-devel] GMime gets support for inline PGP

[Jeffrey Stedfast <fejj gnome org>]

On 3/16/2017 1:45 PM, Daniel Kahn Gillmor wrote:
> On Thu 2017-03-16 09:41:58 -0400, Jeffrey Stedfast wrote:
> > On 3/16/2017 9:28 AM, Jeffrey Stedfast via gmime-devel-list wrote:
> > > > With respect to Inline PGP, though, there are lots of potential bugbears.
> > > > Some questions to make sure these functions are safe to use:
> > > >
> > > >    0) How does GMime deal with data *outside* the OpenPGP signed stanza?
> > > >
> > > >       For example, what happens if Mallory takes an inline-signed message
> > > >       from Bob, appends some text $foo to it outside the message
> > > >       signature, and sends it to Alice?  If Alice calls
> > > >       g_mime_part_openpgp_verify() on the message part, will she see Bob's
> > > >       signature? if so, will $foo will appear in the un-encapsulated
> > > >       message or will it be stripped?
> > > Text outside of the PGP begin/end markers will be stripped.
> > >
> > > Not sure that's the best solution, but... it's simple.
> > FWIW, one of the Balsa devs suggested that perhaps
> > g_mime_part_openpgp_verify() could keep the surrounding text segments
> > but return a GMimeVerifyResults-type of object that has both the
> > GMimeSignatureList and the begin/end byte offsets of the verified text
> > so that the client could use those begin/end offsets to somehow indicate
> > to the user that only that portion of the text has been verified.
> this sounds like something that is very fiddly and likely to be
> difficult to use -- no other consumer of gmime needs to deal with
> bytewise offset counting, does it?

Nope, and I agree... very fiddly. Just thought it was the best idea I've 
seen so far.

> If you really want to do that kind of a split, I think Gaute's
> recommendation of converting it into sub MIME parts might make the most
> sense in terms of fitting with workflows that gmime users are already
> expected to handle in some sensible way.
>
> that is, if the part started out as a text/plain part, you could convert
> it into a bastardized variant of:
>
> A  multipart/mixed
> B    * text/plain (preamble)
> C    * multipart/signed
> D       * text/plain (signed part)
> E       * signature
> F    * text/plain (suffix)
>
> the only issue here is that part D won't actually have any headers or
> MIME structure to it.  And i don't know what you'd do if it was
> something other than text/plain (e.g. a text/html part, which i've
> *also* seen used in inline-signing).

Maybe I'll just wait and see how things shake out with the various 
clients and then absorb the best solution into GMime :)

Jeff