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

[Daniel Kahn Gillmor <dkg fifthhorseman net>]

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?

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

     --dkg