apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: APR: Portable across Operating Systems, or Libraries?
Date Sat, 24 Jan 2009 16:37:29 GMT
William A. Rowe, Jr. wrote:

>>> * common API to access functionality (dbd, ldap, crypto)
>> All do know that crypto in Windows is .NET only from now on?
>> http://blogs.msdn.com/karinm/archive/2009/01/19/capicom-dll-removed-from-windows-sdk-for-windows-7.aspx
>> So will APR crypto be .NET aware from now on too?
> If true; we'll likely substitute openssl in APR.  Would solve des_crypt
> as well.  But I'm not certain we really care, the primitives below capicom
> we use, capicom itself we don't.

There are right now two implementations of the crypto API in apr_util, 
one for OpenSSL, and a second for Mozilla NSS.

I am keen to get a third implementation in there, native Windows crypto 
support (it would take the form of another optional module), but I don't 
have access to a Windows development environment.

When I have some time, we could potentially add gnutls support as well.

Right now the test cases for crypto test that data encrypted by module A 
can be successfully decrypted by module B: this is one of the key design 
goals of the apr_crypto interface: drop in any module relevant to the 
platform, and it should interoperate seamlessly with code running on 
other machines/architectures. As it turns out, interoperability between 
OpenSSL and NSS isn't very good, despite the fact they both are supposed 
to implement standards.


View raw message