thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=debian%2F0.31.2-3 2020-08-10T00:14:36Z 2020-08-10T00:14:36Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:49:49Z urn:sha1:c4541353765dec837c1c2f912b1bf6661827429c Use `makefile-gmake-mode' instead of `makefile-mode' because the former also highlights ifdef et al. while the latter does not. "./Makefile.global" and one "Makefile.local" failed to specify any major mode at all but doing so is necessary because Emacs does not automatically figure out that these are Makefiles (of any flavor). 2020-05-23T01:11:40Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2020-05-12T22:29:37Z urn:sha1:1a34f68a584c2731d33cd5d2a4ee4e6d7faf6a83 In the two places where _notmuch_crypto_decrypt handles multipart/encrypted messages (PGP/MIME), we should also handle PKCS#7 envelopedData (S/MIME). This is insufficient for fully handling S/MIME encrypted data because _notmuch_crypto_decrypt isn't yet actually invoked for envelopedData parts, but that will happen in the following changes. Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net> 2020-05-23T01:11:33Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2020-05-12T22:29:36Z urn:sha1:2b108728c429408c5bf86f1852a205588821286e As we prepare to handle S/MIME-encrypted PKCS#7 EnvelopedData (which is not multipart), we don't want to be limited to passing only GMimeMultipartEncrypted MIME parts to _notmuch_crypto_decrypt. There is no functional change here, just a matter of adjusting how we pass arguments internally. Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net> 2020-04-28T13:35:44Z David Bremner david@tethera.net 2020-04-27T12:24:22Z urn:sha1:ad9c2e91a012920bebfe70bc472d44678abc3259 It turns out that putting inline functions in C header files is not a good idea, and can cause linking problems if the compiler decides not to inline them. In principle this is solvable by using a "static inline" declaration, but this potentially makes a copy in every compilation unit. Since we don't actually care about the performance of this function, just use a non-inline function. 2020-04-16T10:55:23Z Olivier Taïbi oli@olitb.net 2020-04-14T17:38:40Z urn:sha1:b4f593e0e6288666e64d4f3d2651076f5eef1074 Context: I am compiling notmuch on OpenBSD which has a rather old zlib 1.2.3. It seems that the behaviour of gzgets() changed slightly between this version and more recent versions, but the manual does not reflect that change. Note that zlib's manual: - does not specify which error code (Z_OK or Z_STREAM_END) is set when EOF is reached, - does not indicate the meaning of Z_STREAM_END after gzgets(), but based on its meaning as a possible return value of inflate(), I would guess that it means EOF. amended by db: tidy commit message 2020-04-13T20:13:55Z David Bremner david@tethera.net 2020-04-12T23:00:31Z urn:sha1:2c1f783f5f4ad28d89f2e83d7253bae7bba98440 Although (as of 1.2.11) zlib checks this parameter before writing to it, the docs don't promise to keep doing so, so be safe. 2020-01-09T01:12:12Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2019-12-23T17:39:27Z urn:sha1:fd9a951249693b8aa218dd888d39d4a54d63745c 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-09T01:09:21Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2019-12-24T22:05:44Z urn:sha1:5aa60342c86b163848bca6882f34821d4871b849 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> 2019-10-13T12:24:48Z David Bremner david@tethera.net 2019-10-13T12:24:48Z urn:sha1:1979145b91fa85d6952b94db561a46238265d910 2019-10-13T12:18:24Z David Bremner david@tethera.net 2019-10-13T12:18:24Z urn:sha1:49621ea8d5596e707d81ec5aafcfb6a19f864819 Oops. This should make the merge back to master smoother.