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

[Gaute Hope <eg gaute vetsj com>]

First, I think this is great!

Jeffrey Stedfast via gmime-devel-list writes on mars 16, 2017 14:28:
> > -----Original Message-----
> > From: Daniel Kahn Gillmor [mailto:dkg fifthhorseman net]
> >
> >  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.

One solution for separating the encrypted / un-encrypted / signed /
un-signed parts could maybe be to split them into several GMimeParts ? A
MUA could then deal with making it clear to the user which parts are
encrypted and which are not.

> >     cf: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/
> >
> >     For sanity's sake, maybe gmime should only operate on inline PGP
> >     messages that are "Content-Type: text/plain; charset=utf-8", or
> >     perhaps it should transform them to that form first?  I don't know
> >     whether this is safe or not, alas, but it's certainly safer than
> >     interpreting an arbitrary signed bytestream based on contextual
> >     information *outside* the the signature.  :/
> Yea, I'm not a big fan of inline-PGP for the same reasons you listed in your link. It's why I've resisted 
> implementing it for so long...
>
> I mostly did it because I'm trying to save code duplication among software using GMime.

Perhaps one point here is to only support decryption and verification
for inline-pgp to discourage its use?


Regards, gaute