The applications, utilities and libraries using cryptography in Fedora distribution should be converted to use only one cryptography library. The NSS library was chosen for various reasons. The reasons for such conversion are outlined on this wiki page: http://fedoraproject.org/wiki/FedoraCryptoConsolidation More details can be found here: http://fedoraproject.org/wiki/CryptoConsolidationEval The (not exhaustive) list of packages using or containing cryptography algorithms is here: http://fedoraproject.org/wiki/CryptoConsolidationScorecard Here you can find instructions on converting applications using SSL from OpenSSL to NSS: http://fedoraproject.org/wiki/nss_compat_ossl
Your list is missing at least the following OpenSSL users (at least in the qt4 case, it's dlopened): qt4, qca-tls, qca2.
IMHO, nss_compat_ossl needs work to be really usable, right now it's not anywhere near a drop-in replacement, it needs several changes repeated in dozens of packages. It also means losing functionality (from the wiki: "nss_compat_ossl doesn't support SSL compression").
Do you think it would be possible to script some of the changes, like the qt3to4 script which converts Qt 3 code to Qt 4's libQt3Support? Also, if you're going after all the apps containing MD5 code, you're missing a lot of them. Just look at the apps which had to be fixed not to include an inappropriately-licensed implementation, and those are hopefully not the majority. ;-) As far as I know, qt, qt4 and strigi all contain custom MD5 routines, and that's only those I happen to know about.
The list is a little bit outdated as it was produced more than half a year ago and only from the Fedora Core packages before merge. The thing is most of the blocking bugs are very low priority but we want to eventually (in a few years) fix all packages. Also Kevin, can you please fill a separate bug report against nss or nss_compat_ossl and mention there all critical missing things which block porting?
Either you develop a full drop in repacement like we did for FAM with gamin, meaning that no source change is need for upstream, or you need to convince upstream to adopt your new library. I don't see an intermediate approach where the packager is responsible for major code change to be a maintainable solution. Any change to upstream code, be it configure or header or worse code means in practice a fork. I don't want to fork the packages I maintain. Either you have a complete drop in replacement which might be doable, but then you need the balls and workforce to actually *remove* openssl from the distro and put the replacement in, or you work with the gazillion project out there and suggest they add support for your new library. Sorry I'm sorry this can't fly in the current form for me Daniel
For packages which do only SSL the nss_compat_ossl should be the drop-in replacement. Although there is some work yet to be done so there are really no source code changes needed. For applications which use other parts (low level) of OpenSSL the drop-in replacement is mostly not possible, because the OpenSSL API has several limitations making it for example not possible to certify it with FIPS-140-2 Level 2. The bugs filled are basically requests for maintainers to help with the porting effort and especially help with advocating the change upstream. We of course understand that maintaining a fork in Fedora only is not feasible.
It is totally inappropriate to expect a fedora package maintainer to fork an upstream software package to include some unknown crypto software package. Upstream makes choices about which crypto software they intend to use and Fedora does NOT dictate which crypto packages should be used in upstream packages. If you are coming to me as maintainer of a project attempting to get me to change a known working crypto solution for some unknown crypto solution, perhaps fedora bugzilla is the wrong place for this. You should involve yourself on the community mailing list for that package. For the openais package, you can send your proposal to openais.org I can say with 100% certainty this is _never_ going to happen for openais. It would break protocol compatability and introduce unwanted dependencies. openais doesn't use a library for a reason - perhaps you should query the list on the topic for that motivation. Regards -steve
I am more than slightly tempted to close all my bugs WONTFIX. When you have something that is a genuine 100% drop-in, wire-protocol-compatible replacement for OpenSSL, I might be persuaded to make a one-line change in my specfiles to use that. Expecting package maintainers to deal with a sort-of-compatible replacement is not reasonable.
Please file difficiencies that you run into with nsscompatossl against that package. directly drop-in isn't possible, some issues are solved by commenting out code in your application that is already completely handled by NSS (and typically duplicated by every openSSL application out there). There are certainly many areas where nsscompatossl can be better (and potentially help other packagers that run into the same issue. Filing bugs will help us make it better). You can block your bug on the nsscompatossl bug. I'll create a bug for getting a new gnutls package, which gnutls apps can depend on. bob bob
Adding Tracking keyword
triaged
Another friendly way to track progress is https://bugzilla.redhat.com/buglist.cgi?quicksearch=NSS+library+for+cryptography Very few of the bugs have been assigned.
No one seems to have worked on any UI consolidation so far. I think that is an important part of the project and would suggest Mozilla PSM, as I wrote on the wiki page.
This effort is no longer going on. Packagers are encouraged to use the libraries that are preferred from upstream.