[PATCH v2 4/5] cli/show: reindex when we learned new session keys about a message

[Daniel Kahn Gillmor]

On Tue 2018-05-01 22:36:31 -0300, David Bremner wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>
>> +
>> +    if (params->crypto.decrypt == NOTMUCH_DECRYPT_TRUE && session_key_count_error == NOTMUCH_STATUS_SUCCESS) {
>> +	unsigned int new_session_keys = 0;
>> +	if (notmuch_message_count_properties (message, "session-key", &new_session_keys) == NOTMUCH_STATUS_SUCCESS &&
>> +	    new_session_keys > session_keys) {
>> +	    /* try a quiet re-indexing */
>> +	    notmuch_indexopts_t *indexopts = notmuch_database_get_default_indexopts (notmuch_message_get_database (message));
>> +	    if (indexopts) {
>> +		notmuch_indexopts_set_decrypt_policy (indexopts, NOTMUCH_DECRYPT_AUTO);
>> +		status = notmuch_message_reindex (message, indexopts);
>> +		if (status)
>> +		    fprintf (stderr, "Error re-indexing message with --decrypt=stash. (%d) %s\n", status, notmuch_status_to_string (status));
>> +	    }
>> +	}
>> +    }
>
> I'm wondering about the lack of #if HAVE_GMIME_SESSION_KEYS here.  Are
> you relying here on the number of session keys not increasing when
> running a binary without session key support? Is there some advantage to
> doing it this way? It seems a bit harder to reason about.

yes, i'm relying on the number of session keys not increasing if we
don't know how to extract the session keys.  I suppose i could also
imagine some other way that session keys get supplied during a "show",
but then i guess that'd make the reindex moot, which would be a Bad
Thing.

I avoided #if'ing out these sections because i thought the general
strategy was to avoid preprocessor shenanigans where possible, as it
makes the code harder to think about given the combinatorial explosion
of #define options.  But I don't mind wrapping the hunks of this patch
in an #if if the consensus is that this approach is preferable.

   --dkg