William A. Rowe, Jr. wrote:
The plan is to commit this to trunk only (1.4.x and later) - given that the header is private, does this break the ABI rules?The ABI rules generally allow internal changes. However, -1 to this patch, as it is a private function and you haven't actually demonstrated a use case. This implies you are relying on it externally which defeats the 'private' declaration.
The use case is coming - it made no sense to embark on it until there was confirmation that the change was even possible. That's why it was posted and not committed.
Likewise, the module handle is private. apu_dso_load is transparent to the user. If misconfigured, the caller (e.g. mod_ldap/mod_db[dm] caller) is clueless that this might have happened. I suggest proposing a specific API for dealing with the public aspects of apu_dso_load, and have both functions return some "special case" error code for this purpose, which maps to the most recent error result of apu_dso_load.
I have managed to revisit the crypto code, this time round reimplemented from scratch, based on your loadable module mechanism.
To prove that an abstraction was practical, two crypto modules were developed simultaneously, once for OpenSSL and the second for NSS, and after some struggling and lots of help from the NSS people I have managed to get NSS to work correctly.
The test case ensures that the modules interoperate: ie a string encrypted with OpenSSL can be decrypted with NSS, and vice versa.
The plan is to add an MSCAPI / MSCNG based module to make it four modules instead of two, but as I don't have access to an MS development environment I will need some help on that one.
Inspiration for what was possible was based on the xml-security C++ code, which includes crypto modules to support OpenSSL, NSS, CAPI and CNG, though being in C++ it needed to be rewritten.
I am currently going through the code to ensure all the error cases are covered and documented correctly, once that is done I'll have something to show for it.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
