Hi all,Having just finished the next iteration of abstracted crypto support for APR (currently on apr-util-trunk), a problem has cropped up with the assumptions made by mod_ssl and mod_nss.
To date, both mod_ssl and mod_nss have made the assumption that they will be the only crypto modules loaded into the server, and so have "owned" the task of crypto initialisation.
OpenSSL seems to be tolerant of being initialised twice, and so it has been possible for mod_ssl, mod_session_crypto and the external mod_auth_openid to coexist within the same server and this has worked, but by accident.
The same cannot be said however for NSS - NSS requires that a crypto database be specified on initialisation, and if two modules tried to initialise NSS independently of each other, much confusion and brokenness will result.
What I propose to do to fix this for v2.4 and beyond is write a simple module mod_crypto whose job it is to initialise the user's chosen crypto(s) at most once, and serve as a parent module to mod_ssl and any other crypto module that wants to play.
mod_ssl, mod_nss, mod_session_crypto, mod_auth_openid and friends will then have a single mechanism to determine whether crypto has been configured successfully, and which crypto libraries are involved, and none of these modules need stomp on any of the others.
Before embarking on this task, I would like to check whether people believe this to be the optimal solution to the problem, or whether a better solution exists.
Thoughts? Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
