notmuch/util
Daniel Kahn Gillmor fd9a951249 legacy-display: drop tests that try to match headers in a Legacy Display part
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>
2020-01-08 21:12:12 -04:00
..
crypto.c util/crypto: _n_m_crypto_potential_payload returns whether part is the payload 2019-09-01 08:38:11 -03:00
crypto.h util/crypto: _n_m_crypto_potential_payload returns whether part is the payload 2019-09-01 08:38:11 -03:00
error_util.c cppcheck: call va_end in _internal_error 2017-08-30 07:12:13 -03:00
error_util.h util: run uncrustify 2019-06-14 07:41:27 -03:00
gmime-extra.c Merge branch 'release' 2019-10-13 09:24:48 -03:00
gmime-extra.h util: run uncrustify 2019-06-14 07:41:27 -03:00
hex-escape.c util: run uncrustify 2019-06-14 07:41:27 -03:00
hex-escape.h util: run uncrustify 2019-06-14 07:41:27 -03:00
Makefile xutil.c: remove duplicate copies, create new library libutil.a to contain xutil. 2011-10-30 23:09:49 -03:00
Makefile.local repair: set up codebase for repair functionality 2019-09-01 08:20:25 -03:00
repair.c legacy-display: drop tests that try to match headers in a Legacy Display part 2020-01-08 21:12:12 -04:00
repair.h util/repair: identify and repair "Mixed Up" mangled messages 2019-09-15 19:06:31 -04:00
string-util.c util: run uncrustify 2019-06-14 07:41:27 -03:00
string-util.h util: run uncrustify 2019-06-14 07:41:27 -03:00
talloc-extra.c util: add talloc-extra.[ch] 2012-12-30 21:12:11 -04:00
talloc-extra.h util: make remaining headers includable from C++ 2019-03-11 22:26:50 -03:00
unicode-util.c util: run uncrustify 2019-06-14 07:41:27 -03:00
unicode-util.h util: add unicode_word_utf8 2019-05-25 06:51:12 -03:00
util.c util: run uncrustify 2019-06-14 07:41:27 -03:00
util.h fix typos 2018-01-04 20:35:58 -04:00
xutil.c util: run uncrustify 2019-06-14 07:41:27 -03:00
xutil.h util: make remaining headers includable from C++ 2019-03-11 22:26:50 -03:00
zlib-extra.c util: run uncrustify 2019-06-14 07:41:27 -03:00
zlib-extra.h util: make remaining headers includable from C++ 2019-03-11 22:26:50 -03:00