On Mon, Oct 22, 2007 at 08:17:01AM -0400, Bernardo Innocenti wrote: > I remember this topic being discussed some time ago, > but software is fluid and maybe it's time to respin > the topic. > > It would seem a worthwhile goal to unify SSL/TLS > implementations like we did for spell checkers. > Or, if it turns out to be too hard, at least it would > be nice to their pki files. > > We're now shipping no less than 4 different implementations > of SSL: > > - openssl (OpenBSD's implementation) > - nss (Netscape's implementation) > - gnutls (LGPL implementation) > - puretls (Java implementation) > > But which one should replace the others? > > It is not clear to me. Judging from dependencies, OpenSSL, > NSS and gnutls all seem equally popular in Fedora. Which is pretty much where your problems start. Re-writing applications to switch from one impl to another is seriously non-trivial. There is no way in the world you'd want to carry such patches in the Fedora packages because they'd be a huge maintainence time sink whenever a new upstream release came out. So getting any port accepted by the upstream application author has to be the number 1 priority. To do that you need rather compelling reasons to convince the upstream authors. And there is new software coming out all the time using any one of these libraries. IMHO converging on 'one true impl' of SSL is an pretty intractable problem unless someone wants to throw alot of their personal developer time at porting & submitting & merging upstream. > If we are to believe a non-independent comparison, gnutls > looks like the best choice: > > http://www.gnu.org/software/gnutls/comparison.html > > I couldn't find good benchmarks around, but they would > make an important decision factor. The definition of 'best' is rather in the eye of the beholder. The GNUTLS guys will say theirs is best because it has most complete SSL spec coverage. The NSS guys will say theirs is best because it has the FIPS certification and can interact with smart card readers (you know, that pcscd daemon which spins burning your CPU time just in case you ever insert a smartcard). The OpenSSL guys will say, well who knows ?!?! As an app developer I'll say GNU TLS has the most pleasant API to deal with, particularly since it doesn't try to hide POSIX behind a abstraction layer. As a sysadmin GNU TLS certtool is far more pleasant 'openssl' tool. > There are two good reasons not to choose OpenSSL: the > license is GPL incompatible and the ABI gets broken by > upstream very frequently. Strangely enough, OpenSSL in > F8 is linked against nss instead of openssl. Yep, any GPL apps using OpenSSL without an explicit exception need to be fixed, but aside from that its hard to get excited about porting SSL libs. The ABI breakages are likely encouraging any new upstream apps to avoid OpenSSL in favour of GNU TLS too. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
