On 24 Jul 2018, at 16:12, Graham Leggett <minf...@sharp.fm> wrote: > On 24 Jul 2018, at 15:26, Yann Ylavic <ylavic....@gmail.com > <mailto:ylavic....@gmail.com>> wrote: > >>> Having looked at this in more detail, I am -1 on this change on the >>> following basis: >>> >>> - We create a hard link between our crypto libraries and APR itself, >>> which both breaks and renders pointless the existing DSO mechanism, >>> and makes APR significantly more expensive and less attractive to >>> use. >> >> This is being discussed in the other, so I won't my arguments here. > > Just to clarify, I’m -1 (veto).
I have reverted the code that statically linked openssl to apr-util, and restored DSO support, and my veto is now resolved on apr-trunk and apr-util-1.7. To make apr_crypto_png work, I have moved the openssl specific code into apr_crypto_openssl. In order to make the API predictable (and thus testable), the crypto driver and desired cipher can be explicitly chosen. The most likely cause of your trouble with initialising and deinitialising openssl has an initial fix here: http://svn.apache.org/viewvc?view=revision&revision=1861957 The apu_dso_init() function was written in such a way that it could only ever be called once. If you called it multiple times (like httpd does), shutdown becomes unpredictable. If called multiple times with pools that don’t descend from the same parent (like in a unit test), the shutdown is even more unpredictable. apu_dso_init() now reference counts, and is safe to call multiple times from unrelated pools. apu_dso_load() has the same problem as apu_dso_init(), as does each function that calls apu_dso_load(). I am trying to find a general solution for this, failing that we’ll need to apply the same reference count fix to each function. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
