Should we settle on one SSL implementation?
rrelyea at redhat.com
Tue Oct 23 17:22:06 UTC 2007
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
More information about the fedora-devel-list