ensure we are passing through valid function pointers

[kdt3rd]

libdeflate doesn't have the same fallback handling such that if someone resets the pointers, allocations later will crash

[meshula]

Uggh, that's a bit gross. Not your fix, but the pattern in general. My app, SuperEXR does this

• set libdeflate to use SuperEXR malloc/free
• unzip something hooray
• call openexr
• unzip something, kaboom!

mitigation: save/restore the pointers

but sadly

• set libdeflate to use SuperEXR malloc/free
• threaded deflate something, oh this is taking a while
• whatever, this is why crom gave us multithreading right? call openexr
• kaboom!

wonder if we need to strip libdeflate down to almost nothing and completely tuck it under the covers? (and by wonder, I mean, maybe this is the only answer. Has the added benefit that we don't need to trouble package maintainers with how they can impose system deflate, if they wanna, they can just use the hooks you nicely provided and write a deflate adaptor themselves.)

[meshula]

If we force the export macros in libdeflate to static, and tag a small number of functions that libdeflate forget as static as well, we can completely hide libdeflate, and then we can be safe from someone set a memory handler on their copy of libdeflate.

since your change doesn't save and restore the pointers, only sets them, that would make our completely hidden libdeflate threadsafe.

also, I realize package managers love to be able to slap in their own version of everything, but the libdeflate license does not have a copyleft requirement that they be able to do so. Therefore I would say that we "canonically" don't support swapping in user libdeflate libraries.

Furthermore, we make security promises with OpenEXR, such as addressing CVEs. If we allow package managers to swap in libdeflate willy nilly we would violate our security promises.

So my proposal is that

• we hard-smash the libdeflate API macros to static, and
• completely seal the library within OpenEXR for thread safety, and
• it is absolutely not an option to substitute user libdelfate for security reasons

[kdt3rd]

ebiggers/libdeflate#312

[kdt3rd]

I've gone the route of suggesting an alternate path upstream. libdeflate seems active enough that we may not want to vendor it in. Although if we do, I would debate making it such that malloc / free are not required for those structures in the first place (or integrated with the scratch buffer system in the core pipeline code.

[cary-ilm]

LGTM