Well, if a auto-loaded core_ssl module publishes an optional ap_ssl_crypto_init() function, mod_md would sure like to call that.
Cheers, Stefan > Am 23.07.2018 um 12:25 schrieb Yann Ylavic <ylavic....@gmail.com>: > > On Mon, Jul 23, 2018 at 12:05 PM, Plüm, Rüdiger, Vodafone Group > <ruediger.pl...@vodafone.com> wrote: >> >>> Von: Yann Ylavic <ylavic....@gmail.com> >>> >>> Yes, I agree that we have an issue with openssl (< 1.1) >>> loading/unloading/initialization for different modules: core, mod_ssl, >>> mod_md, mod_crypto (via APR), mod_authn_dbd (I wasn't aware of this >>> one using openssl), ... (others?) may all use openssl and in arbitrary >>> order depending on the configuration. >> >> You forgot mod_ldap depending on the LDAP library being used and how this >> Library was compiled to support SSL. > > OK, if this can be determined at compile time we can always hook > something (optional_fn_retrieve looks like a good candidate already). > >>> >>> I wonder which module would provide them though, mod_ssl looks quite >>> straightforward but then it would be a requirement for, e.g. >>> mod_authn_dbd? This does not look right either... >>> Or maybe there could be a way to autoload a mod_openssl (functional >>> only) module? >> >> This looks like the most sane way. It could become very thin once something >> in APR is available. Do we need to do the same for other crypto libraries, >> but >> openssl or do they have a better design with this respect? If it is needed >> for them >> as well, we should have one module that covers them all, not just openssl. > > apr_crypto_lib_init/term() exist for "nss" and "commoncrypto" already > (plus two ENOTIMPLs for some MS implementations/stubs in APR crypto). > We could steal code from there if needed. > > > Regards, > Yann.
