Re: [gmime-devel] extracting session keys from encrypted parts (or: how to augment the interface of GMimeDecryptResult?)

[Jeffrey Stedfast <fejj gnome org>]

On 7/7/2016 10:38 PM, Daniel Kahn Gillmor wrote:
> 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?

Honestly, I'm not sure if it matters if you just add a session key to 
the existing GMimeDecryptResult struct.

I'd probably prefer that over a new subclass.

I know it technically breaks ABI, but meh. What are the scenarios that 
would break for people if we did this? Is it that big of an issue?

Most of the G* libs have moved to making the actual structs private I 
think, which has its pluses for sure (in that you can expand the structs 
w/o breaking ABI), but I always liked the idea of being able to just 
quickly dereference members to get at the internals rather than having 
to use a g_mime_object_type_get_property () API which I always found 
annoying. Then again, I'm not necessary opposed to it either (just more 
explaining why I never bothered).

I suspect most people use the functions to access property values, so 
I'm likely in the minority.

Since sealing all the structs would certainly break API, that's not a 
realistic fix for the short-term, so we're back to either adding the 
member to the struct or subclassing and I'd prefer just adding the 
member assuming it won't break most people using decryption.

Jeff