Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:


> +Supported options for **reindex** include
> +
> +    ``--try-decrypt``
> +
> +        For each message, if it is encrypted, try to decrypt it while
> +        indexing.  If decryption is successful, index the cleartext
> +        itself.  Be aware that the index is likely sufficient to
> +        reconstruct the cleartext of the message itself, so please
> +        ensure that the notmuch message index is adequately
> +        protected. DO NOT USE THIS FLAG without considering the
> +        security of your index.

What can we say about re-indexing without the flag, when the user has
previously indexed cleartext? I guess this is at least partly a question
for Olly: if we delete terms from a xapian document, how recoverable are
those terms and  positions? I suppose it might depend on backend, but
does deleting terms provide at least same level of security as deleting
files in modern file systems (i.e. not much against determined state
level actors, but good enough to defeat most older brothers)

> +# TODO: test removal of a message from the message store between
> +# indexing and reindexing.
> +
> +# TODO: insert the same message into the message store twice, index,
> +# remove one of them from the message store, and then reindex.
> +# reindexing should return a failure but the message should still be
> +# present? -- or what should the semantics be if you ask to reindex a
> +# message whose underlying files have been renamed or moved or
> +# removed?

These tests don't seem hard to impliment, just a bit of drudge work?

TBH I'd have to read source to figure out the degree of robustness
promised by e.g. show/search for renames (without intervening new).
There is some argument for reindexing by path as being a useful use
case, if it could handle renames.

In any case, it would be nice (TM) to document what the current
behaviour is for users.

d