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
Attachment:
signature.asc
Description: PGP signature