Daniel Kahn Gillmor writes:
> Traditionally, encrypted and signed e-mail covers only the body of the
> message. New standards are emerging that are capable of protecting
> the headers as well. In particular, Enigmail and an upcoming version
> of K-9 mail both use the "Memory Hole" approach to
>> https://gitlab.com/jrollins/notmuch/commits/protected-headers-fix
>>
>> All tests pass. Note it requires gmime 3.0 (which tripped me up for a
>> bit since notmuch still implicitly supports older gmime versions).
>>
I didn't get as far as testing this, but
uch_message_get_database:
>>
>> https://gitlab.com/jrollins/notmuch/commits/protected-headers-fix
>>
>> All tests pass. Note it requires gmime 3.0 (which tripped me up for a
>> bit since notmuch still implicitly supports older gmime versions).
>
> Depending on how
Jameson Graef Rollins writes:
> I've pushed a branch of this series rebased against notmuch/release (for
> some reason master is currently a couple commits behind) and fixed to
> reflect the exposure of notmuch_message_get_database:
>
> https://gitlab.com/jrollins/notmuch/co
I've pushed a branch of this series rebased against notmuch/release (for
some reason master is currently a couple commits behind) and fixed to
reflect the exposure of notmuch_message_get_database:
https://gitlab.com/jrollins/notmuch/commits/protected-headers-fix
All tests pass. Note it requires
hat this series does *not* do (yet) is emit any protected headers
from notmuch itself. I think the series can be applied without that,
because just consuming the protected headers and being able to work
with them is a win on its own terms. The series is also careful not
to accidentally leak cl