On Sat, Jan 24, 2009 at 12:06:06AM +0200, Yavor Doganov wrote: > Sylvain Beucler wrote: > > One thing you didn't mention is using GnuTLS. > > Deliberately -- it's well known, and hated among major developers > (why?) [1]. Migration to GnuTLS is not always trivial, and the > openssl compatibility layer (in gnutls-extra, I think) does not work > in all cases and is under GPL (IIRC).
On the other hand, I see a growing number of Debian packages linked against GnuTLS. This won't continue if we don't even mention the GnuTLS project - which needs it, I don't think it's so well-known, be it because people in the field stuck to the 'SSL' acronym rather than its 'TLS' successor. You'll note the effort at Savannah in this regard: http://savannah.gnu.org/tls/ 1) by using 'tls' 2) by using the gnutls tools rather than the openssl ones, the latter being more widely documented by 3rd parties afaics As for "immature".. well I probably don't have to convince you anyway :) > > That's what we recommend > > Migration of an existing package to a new API? I'm a big fan of > GnuTLS, but imposing a specific library as a precondition for project > approval (even as a recommendation) sounds a bit harsh to me, > especially given the fact that several GNU packages have not migrated > for years. It is simply hypocritcial to declare it as some kind of a > policy. The OpenSSL license has been a plague for years and is still a major waste of time in the Free Software community (when do we eventually get SSL/TLS-enabled MySQL in distros?). If people want to use NSS I think it's fine too, the main issue is avoided. We can recommend this one too. Note that I wrote "recommend", not "impose". We do have projects based on openssl at Savannah, but we'd rather help shifting the balance rather than shut up. -- Sylvain
