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 interfaces.. Sorry for the (little) rant, Yann.
