Red Hat Bugzilla – Bug 333741
Fedora CryptoConsolidation tracking bug
Last modified: 2014-10-03 05:11:16 EDT
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:
More details can be found here:
The (not exhaustive) list of packages using or containing cryptography
algorithms is here:
Here you can find instructions on converting applications using SSL from OpenSSL
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
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
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
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.
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
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.
Adding Tracking keyword
Another friendly way to track progress is
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.