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

[Daniel Kahn Gillmor <dkg fifthhorseman net>]

Hi Jeff--

On Tue 2017-03-14 14:49:36 -0400, Jeffrey Stedfast via gmime-devel-list wrote:
> This morning I added some new functions for GMimePart:
>
> g_mime_part_openpgp_encrypt()  // note: can also sign
> g_mime_part_openpgp_decrypt()
> g_mime_part_openpgp_sign()
> g_mime_part_openpgp_verify()
>
> These new functions all operate on the GMimePart to do the various PGP tasks and the end result is that the 
> new content stream will be encrypted, decrypted, signed, or un-encapsulated.
>
> The decrypt and verify methods all return the expected GMimeDecryptResult or GMimeSignatureList objects.

Cool, thanks for tackling this.

Are these functions supposed to deal with PGP/MIME as well, or just for
inline PGP?

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?

 1) same question for OpenPGP encrypted stanzas -- what happens to text
    placed outside (either before or after) the encrypted stanza?

 2) what about messages that have multiple inline OpenPGP-related
    stanzas in the body (either signed or encrypted)?

 3) How does Gmime cope with the fact that the MIME headers themselves
    are not signed or encrypted in any way?

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

Regards,

    --dkg