Hi, as long as it is "that simple" I agree with you. We should try to reduce overhead as much as possbile an concentrate on things which are more important. Ben 2013/2/10 Michael Tremer : > Hello, > > I think it is time to discuss a thing, that has been stuck in my head > for some time now: We have too many SSL implementations in the system. > And as we are already discussion what we can remove from the > distribution (Xen), I'd like to think about the SSL libraries. > > IPFire 3 comes with openssl, GnuTLS, nss and polarssl. They all > basically implement the same protocols, but they differ a bit in their > interfaces, so a lot of projects prefer the one or an other. > > When we had the Lucky Thirteen problem last week, I had to patch all > four libraries. That's redundant work and I don't see any sense in that. > I even see this as a security issue, because it is not easy to keep > track of security issues in all libraries. > > I would like to think about how we can get rid of some of these > libraries: > > * openssl > We cannot get rid of this one because openssl is widely used and I > tend to think that it is the de-facto standard library. > A bit of a problem is the GPL-incompatible license. > > * GnuTLS > This is a much better choice in terms of licenses and GnuTLS is > also widely used. I'd like to keep it. > > * nss > The reason we have this is that RedHat started to move a lot of > their own software to it because nss is FIPS certified. However, > this certification is not important to us at this point in time > and nss is only used by glibc, apr-util and curl. All of them could > be compiler either without nss or with an other SSL library. > > * polarssl > This library came into the distribution very recently and is used > by the authoritative powerdns server. As far as I am aware, powerdns > cannot use any other library. > > Conclusively, we can't (or don't want) to get rid of openssl, GnuTLS and > polarssl. But nss looks like a candidate for me. Opinions? > > -Michael > > _______________________________________________ > Development mailing list > Development(a)lists.ipfire.org > http://lists.ipfire.org/mailman/listinfo/development