docs: clean up documentation about decryption policies

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.
This commit is contained in:
Daniel Kahn Gillmor 2017-12-08 01:24:03 -05:00 committed by David Bremner
parent fccebbaeef
commit be555b9d27

View file

@ -142,7 +142,9 @@ The available configuration items are described below.
**[STORED IN DATABASE]** **[STORED IN DATABASE]**
One of ``false``, ``auto``, ``nostash``, or ``true``. Policy for decrypting encrypted messages during indexing.
Must be one of: ``false``, ``auto``, ``nostash``, or
``true``.
When indexing an encrypted e-mail message, if this variable is When indexing an encrypted e-mail message, if this variable is
set to ``true``, notmuch will try to decrypt the message and set to ``true``, notmuch will try to decrypt the message and
@ -156,6 +158,34 @@ The available configuration items are described below.
``nostash`` is the same as ``true`` except that it will not ``nostash`` is the same as ``true`` except that it will not
stash newly-discovered session keys in the database. stash newly-discovered session keys in the database.
From the command line (i.e. during **notmuch-new(1)**,
**notmuch-insert(1)**, or **notmuch-reindex(1)**), the user
can override the database's stored decryption policy with the
``--decrypt=`` option.
Here is a table that summarizes the functionality of each of
these policies:
+------------------------+-------+------+---------+------+
| | false | auto | nostash | true |
+========================+=======+======+=========+======+
| Index cleartext using | | X | X | X |
| stashed session keys | | | | |
+------------------------+-------+------+---------+------+
| Index cleartext | | | X | X |
| using secret keys | | | | |
+------------------------+-------+------+---------+------+
| Stash session keys | | | | X |
+------------------------+-------+------+---------+------+
| Delete stashed session | X | | | |
| keys on reindex | | | | |
+------------------------+-------+------+---------+------+
Stashed session keys are kept in the database as properties
associated with the message. See ``session-key`` in
**notmuch-properties(7)** for more details about how they can
be useful.
Be aware that the notmuch index is likely sufficient (and a Be aware that the notmuch index is likely sufficient (and a
stashed session key is certainly sufficient) to reconstruct stashed session key is certainly sufficient) to reconstruct
the cleartext of the message itself, so please ensure that the the cleartext of the message itself, so please ensure that the
@ -201,5 +231,6 @@ SEE ALSO
**notmuch-restore(1)**, **notmuch-restore(1)**,
**notmuch-search(1)**, **notmuch-search(1)**,
**notmuch-search-terms(7)**, **notmuch-search-terms(7)**,
**notmuch-properties(7)**,
**notmuch-show(1)**, **notmuch-show(1)**,
**notmuch-tag(1)** **notmuch-tag(1)**