[Libvir] Re: Should we settle on one SSL implementation?

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.
I've asked whether we have a standard layout for /etc/pki before, but no one seems to know.
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)
Make that at least five - ocaml-ocamlnet has a pure-OCaml SSL impl. I'm sure Perl & Python probably have their own too.
But which one should replace the others?
When we implemented encryption in libvirt, we chose gnutls because it has excellent examples which allow you to actually write code to use it in a short period of time. The others have (or we perceived them to have) hideous, confusing or undocumented APIs. For a short while I documented the certificate management code in terms of the OpenSSL command line tools. But after I found out about 'certtool' (part of GnuTLS), I was able to rewrite that documentation and make it considerably simpler[1]. 'certtool' is a lot more sane than the OpenSSL stuff. Nevertheless, I don't think you're going to get rid of the competing SSL libraries. Rewriting code to use a different API is a lot of make-work that no one wants to do, and doesn't contribute much benefit to anyone. Rich. [1] http://libvirt.org/remote.html#Remote_certificates -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

On Monday 22 October 2007 09:47:12 Richard W.M. Jones wrote:
Nevertheless, I don't think you're going to get rid of the competing SSL libraries. Rewriting code to use a different API is a lot of make-work that no one wants to do, and doesn't contribute much benefit to anyone.
This is true and not the aim of the crypto consolidation project. What we are aiming to do is create a --with-nss option for as many packages as feasible and then Fedora can use that in package building. We have also created an openssl compatible API to help ease the transition. -Steve

On Mon, 2007-10-22 at 14:47 +0100, Richard W.M. Jones wrote:
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.
I've asked whether we have a standard layout for /etc/pki before, but no one seems to know.
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)
Make that at least five - ocaml-ocamlnet has a pure-OCaml SSL impl. I'm sure Perl & Python probably have their own too.
But which one should replace the others?
When we implemented encryption in libvirt, we chose gnutls because it has excellent examples which allow you to actually write code to use it in a short period of time. The others have (or we perceived them to have) hideous, confusing or undocumented APIs.
While I'm currently grumpy at gnutls (on debian actually, which is running 2.0), I do agree it's API and read/write callbacks make integrating into an existing event system very nice. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com
participants (3)
-
Andrew Bartlett
-
Richard W.M. Jones
-
Steve Grubb