Skip to content

exim4 vs. OpenSSL vs. GnuTLS

Judging from the long list of exim4 bugs, especially #446036, I find myself between a rock and a hard place, and having to choose between staying with GnuTLS and accepting a probably continuing flow of technical issues, or moving over to OpenSSL, setting an example against GNU software, and probably generating a new flow of license issues.

GnuTLS is the "clearer" solution from a license point of view: The client library is LGPL, and it can thus be safely linked to everything that is part of Debian main. This is the main reason why we decided to use GnuTLS for exim4 years ago, so that we do not need to worry about licensing issues when some other library is linked to by exim some time in the future.

On the other hand, my impression gets stronger and stronger that GnuTLS is not ready for prime-time. There is a truckload of interoperability problems with a number of "remote sides". The most prominent issues are TLS aborts when exim4 is SMTP server for some clients, most notably Incredimail and some mobile Phones from Nokia and other vendors. Most of them can be nailed down to misnegotiation of certain ciphers, but exim does currently not allow disabling of some ciphers at run-time, and - even worse - one would need to disable them completely since one cannot judge in advance whether we are facing a client with issues or one without.

The GnuTLS maintainers of both Debian and upstream try being helpful, but I do not see a long-term solution here.

Additionally, nobody upstream knows its way around the GnuTLS related code in exim, which was contributed by Nikos Mavroyanopoulos years ago. So, there is little chance to get GnuTLS-related bugs ironed out from exim.

OpenSSL, on the other hand, does not have these interoperability issues. At least, I haven't heard of any, and the recommended fix for the reporters of GnuTLS related bugs, "recompile exim with OpenSSL" (which the packaging has been supporting for nearly two years now), usually fixes their problems. I am not in a position to judge whether this is caused by people actually testing against OpenSSL, or OpenSSL generally being more tolerant towards strange implementations, or GnuTLS being buggy or poorly written.

However, building exim4 again OpenSSL may post the license issues that convinced us to use GnuTLS in the first place. Exim itself has an OpenSSL exception, and from what I have been told, the MySQL FLOSS License Exception allows linkage to OpenSSL as well. At least, it does now, since historical evidence in the exim4 package either shows that it used to be a license violation to link MySQL and OpenSSL in the past, or that we (the Debian exim4 team) wrongly thought so. On the other hand, if it is illegal to have OpenSSL and "really" GPLled code in the same execution space, we already have that license violation today, brought to us by PostgreSQL, which links against OpenSSL.

ftpmaster has already indicated that they won't consider an exim4 linked against OpenSSL a license violation and that the packages would go through, the packaging can handle the change by virtue of flipping a switch and rebuilding, but I am still not fully convinced that doing so is the right thing from a political and license point of view. I might still need that final nudge by feedback to this blog article, or have my reluctance fed. Please comment.

No, I do not plan to take this to debian-legal; I'd prefer exim4 staying in Debian main.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Thomas on :

Personally, I'd stay with GnuTLS for the license compatibility with GPL. But then, I've seen software using OpenSSL with lots of functions disabled for license resons.

Sven Hartge on :

I would appreciate a switch to openssl, mainly for reasons already mentioned in the bug report above: strange implementation relevant oddities with GnuTLS, its extremely poor handling of /etc/ssl/certs (if this directory is huge, GnuTLS takes ages reading it, which is an absolute no-go with busier exim4s), entropy issues.

Since I switched to Etch, I am recompiling my own exim4 package with openssl support, because the annoyances the GnuTLS-exim4 caused me where unbearable for the servers I maintain.

Overall I share your view of GnuTLS not beeing ready for prime-time deployment.

Thomas Reifferscheid on :

I would appreciate an official switch to openssl, mainly for reasons already mentioned above.

Christian on :

I'd love to see the official packages linked against OpenSSL, as I've got a few mail hosts, all of them running exim4 with openssl and avoiding a recompile on every upgrade would be a real time and headache saver.

GnuTLS probably isn't ready for production use on (not even high load) mail servers :-/

Martin on :

I'd like to see the packages linked against OpenSSL. The simple reason is that I'm more familiar with OpenSSL than with GnuTLS.

Like Christian, I recompile the package on the very few machines I run.

Simon Josefsson on :

I'd like for exim4 to continue using gnutls. To possibly help with the bug reports, I went over all the gnutls-related bugs I could find. See my writeup at:

http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/

Suresh Ramasubramanian on :

Openssl. And gnutls should possibly be marked as broken till these issues, especially entropy, are ironed out.

License pedantics should not stand in the way of operational / practical issues.

Jon on :

Very late to reply, sorry. I disagree that operational conveniences should trump Debian's core values, but I think that argument is not relevant in this case, since I do not believe the linking issue to be transitive.

Florian Wallner on :

exim4 linked against GnuTLS in its current state is more or less unusable on even moderately busy mialservers. It should be linked against OpenSSL as soon as possible.

Florian

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options