On Fri 2016-12-02 18:52:04 -0500, Jeffrey Stedfast wrote: > On 12/2/2016 3:31 PM, Daniel Kahn Gillmor wrote: >> (and hm, actually, maybe that means we should be zeroing the RAM before >> releasing the stored session key; i can make that change if that sounds >> good to you) > > Yes, please :)
thanks for scrubbing the ram already :)
>> the other advantage for keeping this command is that it makes it clearer
>> in the API which cryptocontexts are capable of this kind of operation.
>> Would it be better to make this function part of the GMimeCryptoContext
>> API instead of the GMimeGpgContext, though?
>
> If the plan is to also add it to the S/MIME context, then yes.
I have no idea whether it makes sense to add it to the S/MIME context --
it might, but i haven't tried. i don't think S/MIME can do decryption
anyway yet, can it?
>> What API would you prefer for a "try-this-session-key" approach? I see
>> two mechanisms:
>>
>> (a) give the session key to the context for any number of subsequent
>> decryptions until it is cleared or re-set:
>>
>> g_mime_gpg_context_set_session_key_for_decryption()
>> g_mime_gpg_context_clear_session_key_for_decryption()
>>
>> This is a bit awkward, though: what should happen if the wrong
>> session key is given; should it fall back to trying to use the
>> available public keys? if so, then we'd need to do some fancy
>> footwork, because gpg simply fails to decrypt if you give it the
>> wrong session key.
>>
>>
>> (b) have some variation on g_mime_multipart_encrypted_decrypt() or
>> g_mime_crypto_context_decrypt(), which has an additional parameter
>> of "session_key".
>
> (b) makes the most sense.
>
> Perhaps g_mime_crypto_context_decrypt_session?
and a g_mime_multipart_encrypted_decrypt_session() as well?
I can work on this patch if it's something that you'd like.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ gmime-devel-list mailing list gmime-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gmime-devel-list
