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.
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.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.
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
<<attachment: smime.p7s>>
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
