my crypto adventure was short-lived and didn't ship (and now LRU'ed
from my brain).
I had this simpler change to our bundled APU 1.5.2 if it helps at all.
index 0f169b4f..958aa068 100644
--- srclib/apr-util/crypto/apr_crypto.c
+++ srclib/apr-util/crypto/apr_crypto.c
@@ -173,10 +173,11 @@ APU_DECLARE(apr_status_t) apr_crypto_get_driver(
return APR_SUCCESS;
}
-#if APU_DSO_BUILD
/* The driver DSO must have exactly the same lifetime as the
* drivers hash table; ignore the passed-in pool */
pool = apr_hash_pool_get(drivers);
+#if APU_DSO_BUILD
#if defined(NETWARE)
apr_snprintf(modname, sizeof(modname), "crypto%s.nlm", name);
On Sun, Sep 12, 2021 at 12:56 PM Yann Ylavic <ylavic....@gmail.com> wrote:
>
> On Fri, Aug 23, 2019 at 2:35 PM Eric Covener <cove...@gmail.com> wrote:
> >
> > I have a question in this area, not necessarily a result of this commit.
> >
> > I have been playing with a new crypto provider, in a non-DSO build,
> > intended to be used with httpd.
> >
> > The provider does have both an initialization and termination API.
> >
> > My issue is a result of the "rootp" being used for the driver hashmap
> > but "pconf" (in the httpd/mod_session_crypto case) being passed to the
> > drivers init() function the first time it's loaded. This means at
> > graceful restart, cleanups registered by the drivers init() function
> > will run, but apr_crypto_term will not, and the next call to get the
> > driver will not re-run the init().
> >
> > Making the lifetimes match either way fixes my test -- either moving
> > the "rootp" stuff to DSO-only for apr_crypto_init or by passing
> > "rootp" to the DRIVER_LOAD macro for non-DSO init.
> >
> > Any opinions?
>
> Was this resolved?
>
> It seems to me that in the !DSO case we should init the driver with
> the given pool and call init each time like in the DSO case.
> Something like the attached patch?
>
>
> Cheers;
> Yann.
--
Eric Covener
cove...@gmail.com
