On Wed 2019-11-27 08:33:41 -0700, Sean Whitton wrote: > Hello, > > On Mon 25 Nov 2019 at 04:45PM -05, Daniel Kahn Gillmor wrote: > >> Fully decode the encrypted part before passing it to any decryption >> mechanism. > > I can go ahead and add "no functional change" to this commit message > right?
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, --dkg
signature.asc
Description: PGP signature
