Hi GMime folks-- I'm interested in extracting session keys during decryption, with the idea of creating a mailbox indexing tool that caches session keys to secure storage. This would avoid expensive asymmetric operations on all access to a message after the first, making a much more performant mail application, especially when rendering long threads of encrypted mail. However, i don't see a straightforward way to include a session key in GMimeDecryptResult without breaking the ABI because the struct _GMimeDecryptResult is included in the headers and is documented as struct GMimeDecryptResult explicitly in the documentation. is there a reason that the structure of GMimeDecryptResult is exposed? All of the members of GMimeDecryptResult are accessible via setter and getter functions, so it doesn't appear to need to be exposed. If the struct were opaque, then new versions of GMime could safely add members to the GMimeDecryptResult without worrying about breaking ABI compatibility during an upgrade. (the API would only grow, which is safe for backward compatibility) I could work on a patchset that adds a session key to this object, if there's interest. But would an ABI transition be needed? and if so, how would that be handled? Other structs (like GMimeCryptoContext) are similarly present in the header files, but their structure is not listed in the documentation. So maybe we just need to ensure that no one is using the struct's declaration explicitly and clean up the documentation? Another alternative would be to implement something like GMimeDecryptResultWithSessionKey, which would inherit from GMimeDecryptResult. The caller of g_mime_crypto_context_decrypt() could then test the type via GObject and be able to extract a session key if it was the new type. Would that be a better/safer approach? --dkg
Attachment:
signature.asc
Description: PGP signature