These tests were an attempt to establish that the content of the
"Legacy Display" part is the same as the actual protected headers of
the message. But this is more conservative than we need to be.
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
section 5.3 makes clear that the Legacy Display part is purely
decorative, and section 5.2.1 clarifies that the detection can be done
purely by MIME structure and Content-Type alone.
Furthermore, now that we're accepting text/plain Legacy Display parts,
it's not clear the lines in the Legacy Display part should be
interpreted as needing an exact string match (e.g. "real" headers are
likely to be RFC 2047 encoded, but the text/plain Legacy Display part
probably should not be).
The concerns that motivated this test in the past were twofold: that
we might accidentally hide some information from the reader of the
message that they should have available to them, or that we could
introduce a covert channel that would be invisible to other clients.
I no longer think these are significant concerns:
a) There will be no accidental misidentification of a Legacy Display
part. The identification of the Legacy Display part is
unambiguous due to MIME structure and Content-Type. MIME
structure MUST be the first child part of a two-part
multipart/mixed Cryptographic Payload. And the
protected-headers=v1 content-type parameter must be present on
both the cryptographic payload and the legacy display part, so no
one would accidentally generate this structure and have it be
accidentally matched.
b) As for creating a covert channel, many such channels already
exist. For example, non-standard e-mail headers, custom MIME
types, unusual MIME structures, etc, all make it possible to ship
some content in a message that will be visible in some MUAs but
not in others. This doesn't make the situation demonstrably
worse.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
Makes it clear that the "Legacy Display" part of an encrypted message
with protected headers can (and indeed, should) be of content-type
text/plain, though some clients still generate the Legacy Display part
as content-type text/rfc822-headers. Notmuch should recognize the
part whichever of the two content-types it uses.
See also discussion in
https://github.com/autocrypt/protected-headers/issues/23 for why the
community of implementers is moving in the direction of text/plain.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Implement a functional identification and repair process for "Mixed
Up" MIME messages as described in
https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling-00#section-4.1
The detection test is not entirely complete, in that it does not
verify the contents of the latter two message subparts, but this is
probably safe to skip, because those two parts are unlikely to be
readable anyway, and the only part we are effectively omitting (the
first subpart) is guaranteed to be empty anyway, so its removal can be
reversed if you want to do so. I've left FIXMEs in the code so that
anyone excited about adding these additional checks can see where to
put them in.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This is a utility function designed to make it easier to
"fast-forward" past a legacy-display part associated with a
cryptographic envelope, and show the user the intended message body.
The bulk of the ugliness in here is in the test function
_notmuch_crypto_payload_has_legacy_display, which tests all of the
things we'd expect to be true in a a cryptographic payload that
contains a legacy display part.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This adds no functionality directly, but is a useful starting point
for adding new repair functionality.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
