Re: svn commit: r1837435 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c ssl_engine_init.c
I am not under any time constraints here. Most people do not seem to run into this issue. So, stay hydrated in this weather and enjoy your upcoming vacation.
I think having some common *ssl lib init/lifetime handling in httpd is a Good Thing. However, it sounds as if we would not backport such an extra module to 2.4.x and then it is good to rely on good APR support, require something new enough for a trunk httpd and be done with it.
At least it sounds like this on a first read to me.
> Am 06.08.2018 um 16:14 schrieb Yann Ylavic <ylavic.dev@xxxxxxxxx>:
> Hi Stefan,
> On Mon, Aug 6, 2018 at 1:47 PM, stefan@xxxxxxxxxxx <stefan@xxxxxxxxxxx> wrote:
>> Yann and Rüdiger, looking at this, I am thinking about how to improve
>> mod_md's init of openssl. Basically, if mod_ssl + mod_md is loaded,
>> mod_md does not have to do anything, it seems.
>> However, there is a slim chance that someone has another ssl module
>> (or none?) and what should mod_md do then? I can copy the crypto
>> parts of the pre_config and cleanup code, but given the ever
>> increasing version number checks...is there a better way?
> I'm currently working on changing APR's apu_dso_load() so that it can
> work on the given pool (user controlled lifetime) and also
> (optionally) init/deinit the lib.
> This is needed (I think) for APR's self handling of its DSOs (focusing
> on apr_crypto and openssl for now).
> With this in e.g. APR 1.7 (at best), we can simply call
> apr_crypto_load_lib("openssl") in each module using openssl like we
> currently do in trunk (the dynamic linking part in APR trunk is
> currently being disputed, so I'm on the DSO way now...).
> Anyway we can't mandate APR 1.7 (at best) in httpd, so I was thinking
> of copying interesting bits of apu_dso_load() into e.g. ap_dso_load()
> (or a more openssl only version of it), so that it works in httpd with
> earlier APR versions too.
> So we'd configure, build and install something like
> "mod_ssl_openssl.so/dll" (itself dynamically linked with
> libcrypto/ssl), that is when a module needs it. Thus we'd
> ap_dso_load() it in mod_ssl/md/session/... at pre_config time so that
> the load/unload and init/deinit work once for all according to the
> given pool (usually the same one, pconf).
> Would that work for you?
> I'm not too far from having something for APR, and expecting the ap_
> part to be quite straight forward (and mostly copy/paste).
> Possibly something this week, otherwise after my vacations (more about