Re: [PATCH 03/18] crypto: use stashed session-key properties for decryption, if available

[David Bremner <david@tethera.net>]

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

> I also
>> don't know how motivated gmime upstream is to fix bugs in 2.6; I could
>> certainly understand if the answer was "not very".
>
> I believe the answer is "not very" -- but if there are serious bugs (i
> don't think we've talked about any of this stuff as bugs in gmime) then
> we should probably try to raise them with him.

I think Jani tried a bit to narrow it down, but didn't succeed. Part of the
problem (which I suspect is endemic to crypto issues) is that we don't
have public test cases.

>
>> There is, by the way, a function notmuch_built_with that can be used to
>> introspect the library as to what optional features it is built
>> with. It's used in notmuch_config to report back to the user about the
>> presence of optional features.
>
> Is there any naming convention for these features?  do you want me to
> add a "session-key" label with a future revision of this branch?  or are
> you asking for something else?

It could be a followup, but yeah, if there is some feature that is
sometimes compiled in, and sometimes not, then it should be listed along
with the others. For whatever reason, the existing convention is
'session_key'

This discussion does make me think there should probably be a test in
configure that sets a corresponding feature macro
HAVE_GMIME_SESSION_KEYS, in a manner similar to HAVE_XAPIAN_COMPACT
(possibly just centralizing the version comparison currently used).

d