apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: apu_dso_load and errors
Date Sat, 06 Sep 2008 19:05:20 GMT
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
--

Mime
View raw message