On Tue 2018-05-01 22:36:31 -0300, David Bremner wrote: > Daniel Kahn Gillmor <dkg@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 _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch