On Thu, Feb 28, 2019 at 12:06 AM William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Any other concerns ahead of 1.7.0?

There are some backports I need to revert, the dynamic linking (as
opposed to dynamic loading) of apr_crypto libraries -1'ed by Graham
(see discussion in r1833359 and r1833421 threads), and thus the new
PRNG stuff depending on a single library init/deinit point in APR and
(hopefully) as much direct as possible calls to the underlying crypto
lib primitives (i.e. no insane indirections).

Even if I find that DSOs in crypto code complicate a lot of things
(which usually goes against cryptography), I tried to work on keeping
them and being able to load/unload/reload at wish, but got blocked at
some point with openssl refusing to reload. I gave up due to lack of
time (status: WIP in my tree).
In short more work and fighting against the libs vs dynamic loader is
needed (on a lib/version case by case basis), no very exciting..

So I'll revert these in 1.7, but I feel a bit sour about the status
quo because currently one can't use APR and some other stuff with the
same crypto library; who is responsible for the init/deinit? (e.g.
mod_ssl vs mod_crypto, not to talk about potential APR's PRNG at the
httpd/core level...)
We have this mess today, APR looks like a central place to
init/deinit, and blocking progress because it's not how "drivers"
should work and so on is not helpful (who wants to load multiple
crypto libs? and even though why dynamic linking wouldn't work?). We
need simple/working/efficient things, not fights against the libs, and
we'd better put energy in new/nowadays/unbroken crypto algorithms

Sorry for the (little) rant,

Reply via email to