https://issues.apache.org/bugzilla/show_bug.cgi?id=56919
--- Comment #9 from Alex Bligh <a...@alex.org.uk> ---
I'm not sure what the proper way to fix is this.
It's tempting to call CRYPTO_cleanup_all_ex_data, but I don't think that's the
right solution. Firstly ssl_cleanup_pre_config says:
/* Also don't call CRYPTO_cleanup_all_ex_data here; any registered
* ex_data indices may have been cached in static variables in
* OpenSSL; removing them may cause havoc. Notably, with OpenSSL
* versions >= 0.9.8f, COMP_CTX cleanups would not be run, which
* could result in a per-connection memory leak (!). */
Secondly some other ssl user (for instance a DBD driver using an SSL interface
to the database) may not take kindly to us stomping on its data.
It's tempting to remove the index that X509_get_ex_new_index added, removing
the data, save that as far as I can see openssl doesn't have an API call to do
that.
That would leave us attempting to ensure that every single object that mod_ssl
allocates is freed. But firstly, I'm not sure how to do that, and secondly this
won't fix the problem where there is some other ssl user that also allocates
objects. It would also be inherently fragile.
The final option would be to rewrite the stapling code so it didn't use ex_data
at all. To me this seems like the best route, but I don't understand the
stapling code well enough to do it.
Is there some easier option I have missed?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
