On 04/06/2014 05:15 AM, Guyzmo wrote: > I indeed agree with this view, and I think the best process would be > to have the MUA decrypt and index an encrypted mail when the user wants > it to be indexed. So the user do not get really highly secret messages > disclosable by the index, and for the others take that kind of risk.
At the moment, notmuch has a "no-modify" policy to the mail storage, with the exception of changing a few well-known flags on maildir names. I would be pretty sad to see that change, and i don't think that's a good idea for notmuch in general. let's keep access to the mail store as read-only as possible. additionally, stripping encryption in some cases would mean stripping cryptographic signatures (e.g. most PGP/MIME encrypted messages are encrypted+signed, but the signature is a separate PGP part and not a MIME part) i think it would be bad to lose cryptographic signatures in this case. That said, i agree that there are some scenarios where having well-indexed mail storage even for the cleartext of encrypted messages would be useful and could even be done with some level of safety (e.g. where the index is itself stored on an encrypted filesystem -- notmuch has no explicit/builtin support for an encrypted index today). I think the most sensible way to approach this goal for notmuch would be a two-part series of generic notmuch enhancements, which could then be leveraged by those who need them into a cleartext index for those messages that they are willing to take a risk on. here are the notmuch enhancements: * notmuch new id:$msgid This capability would allow notmuch to reindex a given message, clearing the entire index of any old references and adding new references to the current filter. * notmuch new --filter=$foo The --filter option for notmuch new (or something similar) would pass each message in question through a pipeline-style filter and operate on it the stdout of the filter, rather than the raw message. Given these two enhancements (some of which may be already underway, i confess i haven't been following closely), it wouldn't be much extra effort for someone to implement a filter that strips encryption from the message. (this might still have the problem mentioned above about also stripping PGP/MIME signatures, but the signatures and the decrypted message itself would remain intact so they could be shown directly by notmuch show without trouble). once such a filter was in place, my personal preference would be that the messages would be imported as ciphertext initially, but then when an end-user-facing MUA gets the user to decrypt a message that has not been indexed with this filter, it could offer a button that says "index this message in cleartext (will leak contents to anyone who can read the index)" --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch