notmuch/doc/man1, branch 0.26_rc0

cli/new: support // in new.ignore

2017-12-15T11:54:33Z

Add support for using // style regular expressions in new.ignore, mixed with the old style verbatim file and directory basenames. The regex is matched against the relative path from the database path.

cli: add support for only printing the addresses in notmuch address

2017-12-15T01:28:50Z

The notmuch address output is much more useful for scripts with just the addresses printed. Support this using the --output=address option.

docs: clean up documentation about decryption policies

2017-12-08T12:08:47Z

Now that the range of sensible decryption policies has come into full view, we take a bit of space to document the distinctions. Most people will use either "auto" or "true" -- but we provide "false" and "nostash" to handle use cases that might reasonably be requested. Note also that these can be combined in sensible ways. Like, if your mail comes in regularly to a service that doesn't have access to your secret keys, but does have access to your index, and you feel comfortable adding selected encrypted messages to the index after you've read them, you could stay in "auto" normally, and then when you find yourself reading an indexable message (e.g. one you want to be able to search for in the future, and that you don't mind exposing to whatever entities have access to your inde), you can do: notmuch reindex --decrypt=true id:whatever@example.biz That leaves your default the same (still "auto") but you get the cleartext index and stashed session key benefits for that particular message.

crypto: add --decrypt=nostash to avoid stashing session keys

2017-12-08T12:08:47Z

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.

crypto: actually stash session keys when decrypt=true

2017-12-08T12:08:47Z

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.

cli/reindex: destroy stashed session keys when --decrypt=false

2017-12-08T12:08:47Z

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.

cli/new, insert, reindex: change index.decrypt to "auto" by default

2017-12-08T12:08:46Z

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.

cli/new, insert, reindex: update documentation for --decrypt=auto

2017-12-08T12:08:46Z

we also include --decrypt=auto in the tab completion.

cli/show: use decryption policy "auto" by default.

2017-12-08T12:08:46Z

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.

cli/reply: use decryption policy "auto" by default.

2017-12-08T12:08:46Z

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.