Re: mod_ssl and openssl 1.0.2 initialization
Well, if a auto-loaded core_ssl module publishes
an optional ap_ssl_crypto_init() function, mod_md
would sure like to call that.
> Am 23.07.2018 um 12:25 schrieb Yann Ylavic <ylavic.dev@xxxxxxxxx>:
> On Mon, Jul 23, 2018 at 12:05 PM, Plüm, Rüdiger, Vodafone Group
> <ruediger.pluem@xxxxxxxxxxxx> wrote:
>>> Von: Yann Ylavic <ylavic.dev@xxxxxxxxx>
>>> 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.