Should we settle on one SSL implementation?

[Robert Relyea]

Jeremy Katz wrote:
>
> Adding more compile time options isn't necessarily the answer, though.
> It makes maintenance a bit of a pain (now I have to maintain two
> versions of the same code, oh goodie!) and also ends up making things a
> little bit less obvious.  Maybe some projects will be willing to go this
> route, but I suspect it's not going to be a slam dunk, especially given
> the breadth of software being impacted.  Some of which probably doesn't
> even have a real maintained upstream anymore
>   
I really depends on the extent of the compile time options.
The conversions that have already been done were either very small 
changes, or larger changes that abstract the crypto usage a little 
better with very small diffs between the various crypto packages.

So far there hasn't been a huge problem getting upstream to accept the 
ability to use another crypto package.
> The idea of getting to where we can just have a fully drop-in
> replacement for all of openssl and gnutls that backend to NSS is going
> to end up being far more palatable for many packages.  It's not going to
> be as easy for those working on said drop-in replacements, though.
>   
A fully drop-in replacement with the existing API's isn't possible. Part 
of the reason we have to do this conversion is the API's are not 
conducive to proper validation (or proper crypto hygeine). Fortunately 
most applications do not need those API's, so our 90% replacements 
should work. Applications that are using the lower-level raw crypto need 
to be refactored to allow them to work with not only properly validated 
crypto, but also other hardware crypto engines which for security 
reasons do not release key material.

Another area that's a real problem is certificate validation. gnutls 
itself doe not do certificate validation (that's left to other 
packages), openssl provided helper functions and pushes everything else 
on the client. That means support for Crl's, OCSP, and PKIX would need 
to be added to each an every application. With NSS, there is a single 
call to validate certificates, and support for OCSP and CRL's come 
automatically. Most of the conversions have simplified cert processing 
in the NSS side.

At this point we need to start converting packages to see where the 
deficiencies in our helper conversion packages are. As packages fail we 
need to evaluate whether the conversion failure was a true deficiency in 
the conversion package, or is this an area that we need to move the 
application to a more generic interface anyway.

bob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071023/155867ee/attachment.bin>