shared link libssl / libcrypto

[xnox]

I am wondering if it is possible to do a shared linking to libcrypto/libssl at build time, instead of dlopen.

Would something like that be supported or interesting to implement?

Ideally I wish to have go binaries have a shared link on libssl.so.3, rather than them fail at runtime when they fail to dlopen it.

[dagood]

I feel like this would be feasible, because the implementation of each "bridge" function is driven by macros that I believe could be used to generate direct calls rather than dlopen-based ones: https://github.com/golang-fips/openssl/blob/v2/shims.h#L112. Conceptually, that's interesting.

I'm less sure about how this would be supported in concert with the dlopen implementation. I would be concerned that it might negatively impact maintainability. (I imagine at the very least, a build tag for each dynamic-link-compatible OpenSSL version would be necessary, and each one added to the testing workflow.)

As far as usage within Microsoft goes, there's no known reason someone would need dynamic linking rather than dynamic loading, so strictly from that perspective, it doesn't seem useful.

Side question: would this implementation also happen to support static linking? I think it might just be a matter of changing the C build flags at that point, and although we can't use this inside Microsoft (by policy) it's something that there's been interest for in the past. Whether FIPS compliance could be achieved this way is a different question. 😄

[xnox]

I'm not too sure if one can statically link libssl/libcrypto and yet still be able to load fips provider. Or otherwise put the statically linked libssl/libcrypto into FIPS mode for older releases.