control: tag -1 +pending Hello,
On Thu 28 Nov 2019 at 01:00AM -05, Daniel Kahn Gillmor wrote: > Hm, this is actually *not quite* "no functional change". > > In particular, it means we're passing around a bytestream version of the > inner part, not the potentially-encoded (base64 or quoted-printable) > string-like variant. > > This actually will have an impact on how we handle some messages -- it's > not just a code reorganization. for example, if someone were to make an > OpenPGP encrypted message, and they didn't ASCII-armor the encrypted > part, but rather attached it as a binary blob, then their MUA would > probably wrap it in a Content-Transfer-Encoding: base64. > > If we then passed the un-decoded blob to an OpenPGP decryptor, it > wouldn't have the OpenPGP armor header, and it wouldn't have the right > bytestream to mark it as a "raw" OpenPGP packet. so the decryptor > wouldn't be able to handle it. > > In practice, all the encrypted messages that i've found to throw at > email-print-mime-structure thus far have had OpenPGP-specific > ASCII-Armoring already, and thus haven't needed to be decoded, and for > *those* messages, there is no functional change needed. > > But that won't be the case for the PKCS7 (S/MIME) objects we encounter > later in the series, so it's nice to also make this more robust for > PGP/MIME messages as well. > > Hope this makes sense, It does, thank you. Adding a link to your e-mail to the changelog. -- Sean Whitton
