summaryrefslogtreecommitdiff
path: root/test/T357-index-decryption.sh
AgeCommit message (Collapse)Author
2017-12-29cli/show: make --decrypt take a keyword.Daniel Kahn Gillmor
We also expand tab completion for it, update the emacs bindings, and update T350, T357, and T450 to match. Make use of the bool-to-keyword backward-compatibility feature.
2017-12-08crypto: add --decrypt=nostash to avoid stashing session keysDaniel Kahn Gillmor
Here's the configuration choice for people who want a cleartext index, but don't want stashed session keys. Interestingly, this "nostash" decryption policy is actually the same policy that should be used by "notmuch show" and "notmuch reply", since they never modify the index or database when they are invoked with --decrypt. We take advantage of this parallel to tune the behavior of those programs so that we're not requesting session keys from GnuPG during "show" and "reply" that we would then otherwise just throw away.
2017-12-08crypto: actually stash session keys when decrypt=trueDaniel Kahn Gillmor
If you're going to store the cleartext index of an encrypted message, in most situations you might just as well store the session key. Doing this storage has efficiency and recoverability advantages. Combined with a schedule of regular OpenPGP subkey rotation and destruction, this can also offer security benefits, like "deletable e-mail", which is the store-and-forward analog to "forward secrecy". But wait, i hear you saying, i have a special need to store cleartext indexes but it's really bad for me to store session keys! Maybe (let's imagine) i get lots of e-mails with incriminating photos attached, and i want to be able to search for them by the text in the e-mail, but i don't want someone with access to the index to be actually able to see the photos themselves. Fret not, the next patch in this series will support your wacky uncommon use case.
2017-12-08cli/reindex: destroy stashed session keys when --decrypt=falseDaniel Kahn Gillmor
There are some situations where the user wants to get rid of the cleartext index of a message. For example, if they're indexing encrypted messages normally, but suddenly they run across a message that they really don't want any trace of in their index. In that case, the natural thing to do is: notmuch reindex --decrypt=false id:whatever@example.biz But of course, clearing the cleartext index without clearing the stashed session key is just silly. So we do the expected thing and also destroy any stashed session keys while we're destroying the index of the cleartext. Note that stashed session keys are stored in the xapian database, but xapian does not currently allow safe deletion (see https://trac.xapian.org/ticket/742). As a workaround, after removing session keys and cleartext material from the database, the user probably should do something like "notmuch compact" to try to purge whatever recoverable data is left in the xapian freelist. This problem really needs to be addressed within xapian, though, if we want it fixed right.
2017-12-08cli/new, insert, reindex: change index.decrypt to "auto" by defaultDaniel Kahn Gillmor
The new "auto" decryption policy is not only good for "notmuch show" and "notmuch reindex". It's also useful for indexing messages -- there's no good reason to not try to go ahead and index the cleartext of a message that we have a stashed session key for. This change updates the defaults and tunes the test suite to make sure that they have taken effect.
2017-12-08cli/show: use decryption policy "auto" by default.Daniel Kahn Gillmor
When showing a message, if the user doesn't specify --decrypt= at all, but a stashed session key is known to notmuch, notmuch should just go ahead and try to decrypt the message with the session key (without bothering the user for access to their asymmetric secret key). The user can disable this at the command line with --decrypt=false if they really don't want to look at the e-mail that they've asked notmuch to show them. and of course, "notmuch show --decrypt" still works for accessing the user's secret keys if necessary.
2017-12-08cli/reply: use decryption policy "auto" by default.Daniel Kahn Gillmor
If the user doesn't specify --decrypt= at all, but a stashed session key is known to notmuch, when replying to an encrypted message, notmuch should just go ahead and decrypt. The user can disable this at the command line with --decrypt=false, though it's not clear why they would ever want to do that.
2017-12-08crypto: new decryption policy "auto"Daniel Kahn Gillmor
This new automatic decryption policy should make it possible to decrypt messages that we have stashed session keys for, without incurring a call to the user's asymmetric keys.
2017-12-08lib: convert notmuch decryption policy to an enumDaniel Kahn Gillmor
Future patches in this series will introduce new policies; this merely readies the way for them. We also convert --try-decrypt to a keyword argument instead of a boolean.
2017-12-08indexing: Change from try_decrypt to decryptDaniel Kahn Gillmor
the command-line interface for indexing (reindex, new, insert) used --try-decrypt; and the configuration records used index.try_decrypt. But by comparison with "show" and "reply", there doesn't seem to be any reason for the "try" prefix. This changeset adjusts the command-line interface and the configuration interface. For the moment, i've left indexopts_{set,get}_try_decrypt alone. The subsequent changeset will address those.
2017-12-05test: session keys are known broken without session key supportDaniel Kahn Gillmor
If the version of GMime we're building against doesn't support session key extraction or re-use, mark the tests that rely on session key capabilities as known-broken. This should resolve test suite failures on ubuntu trusty and debian jessie and earlier, which have GMime 2.6.20 -- session key support was introduced in GMime 2.6.21.
2017-12-04crypto: Test restore of cleartext index from stashed session keysDaniel Kahn Gillmor
If you've got a notmuch dump that includes stashed session keys for every decrypted message, and you've got your message archive, you should be able to get back to the same index that you had before. Here we add a simple test that give some flavor of how that works.
2017-10-21cli/reindex: add --try-decrypt=(true|false)Daniel Kahn Gillmor
Enable override of the index.try_decrypt setting on a per-run basis when invoking "notmuch reindex". This allows the possibility of (for example) an emacs keybinding that adds the cleartext of the currently shown decrypted message to the index, making it searchable in the future. It also enables one-time indexing of all messages matching some query, like so: notmuch reindex tag:encrypted and\ not property:index.decryption=success and\ from:alice@example.org We also update the documentation and tab completion, and add a few more tests.
2017-10-21cli/insert: add --try-decrypt=(true|false)Daniel Kahn Gillmor
Enable override of the index.try_decrypt setting on a per-message basis when invoking "notmuch insert". We also update the documentation and tab completion, and add more tests.
2017-10-21cli/new: add --try-decrypt=(true|false)Daniel Kahn Gillmor
Enable override of the index.try_decrypt setting during "notmuch new" on a per-invocation basis. We update the documentation and tab completion, and also add a test.