Should we settle on one SSL implementation?

[Jeremy Katz]

On Tue, 2007-10-23 at 08:46 -0400, Steve Grubb wrote:
> On Monday 22 October 2007 19:03:46 Thomas M Steenholdt wrote:
> > Bernardo Innocenti wrote:
> > > 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.
> >
> > I really don't think its our job to decide which SSL implementation is
> > used by the various different projects.
> 
> You are right, we don't want to decide anyone's preference. What we need to 
> accomplish is adding another choice for projects. This way it can be compiled 
> against either gnutls/openssl/home brew crypto, or NSS which is FIPS-140-2 
> certified and has all the right interfaces for central configuration control.

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

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.

It's also probably worth looking into why new projects choose gnutls or
openssl instead of NSS and trying to make that experience better so that
new projects will use NSS

Jeremy