The investigation that prompted that email was in this bug report, ITS#5361 and it revealed that GnuTLS had more serious problems than could be addressed in a simple “bug fix.” The software was clearly broken from the get-go, and the project’s developers were also clearly too inexperienced to even understand what was so broken about it. 3 years later they still didn’t understand, and continued in ignorance despite multiple attempts to explain. Fast-forward to today and you have the whole internet abuzz saying “this is proof that open source is no better than closed source.”
But let’s take a closer look at the situation:
The OpenLDAP Project has supported OpenSSL since early 2000. We added support for GnuTLS grudgingly, at the behest of Stanford University and the Debian Project. Even before these architectural issues in GnuTLS came to light, there were strong reasons for this reluctance. The most obvious is tied to the GnuTLS project’s questionable development pace. Consider - the OpenSSL code has been public since 1994 (when it was still called SSLeay), but since the first public releases (numbered 0.4.0) it didn’t reach version 1.0.0 until March 2010. The OpenSSL developers were not novices, nor were they particularly slow coders. (Indeed, Howard was a contributor to OpenSSL back in the 1990s…) They were simply careful - very, very careful. This is security software, you *need* to be careful when you’re writing this stuff. You want to be very sure of yourself before you declare a project like this “stable” and “production-ready.”
In contrast, the GnuTLS project started in 2000 and went from version 0.0.7 in January 2001 to version 1.0.0 in December 2003. Today it’s already at version 126.96.36.199. Quite a rapid pace of development! If you look at the commit history for 1.0.0 you’ll see something quite interesting - most of the commits have no log message, no explanation for why the code was changed. The two of these characteristics combined together are a major red flag - these developers are careless. Reckless, even.
The investigation of ITS#5361 told the same story. Critical changes (like the one creating this bug) were being made in the code, without comment or explanation in either the commit history or in the developers’ mailing list. In contrast, every little change in OpenSSL is hashed out at length on their developers’ list. The lack of discussion is contrary to the open source development process. The lack of commit logs is contrary to all good programming practice, whether open source or proprietary.
As for the bug of the week, the latest problem, there’s a very good analysis written here. To summarize, the GnuTLS code uses multiple conventions to return success/fail status from functions, and the coder mixed up which was which. Again, errors of this type are made by novices, and reflect code that was poorly designed in the first place. In well-designed code, you pick a single programming convention and stick with it. (Some folks may be recalling Emerson’s “a foolish consistency is the hobgoblin of little minds” here. But the point of writing software is to write something easily understood by the simplest mind of all - the computer. Not to mention that writing code that is easily misunderstood makes future programmers’ jobs much harder.) In short - in any programming language, there may be multiple ways to solve a problem. But the Right Way is to do it only One Way. Pick an approach and use it consistently and exclusively.
Of course the problems in GnuTLS aren’t just limited to poor programming practices. The other major issue is that the GnuTLS developers just don’t know very much about TLS. Their total unfamiliarity with public key certificates and how they are used utterly disqualifies them from working on this type of software. As noted in our ITS#5991 the design of GnuTLS’ certificate management makes it impossible for them to distinguish between CertificateAuthority certificates and end-user certificates. Ignorance can of course be cured, but the fact that critical failures keep cropping up in their certificate handling code indicates that they still haven’t addressed this gap in their knowledge. (And again, these faults are deeper than simple typos - the code design is inherently wrong.)
Ultimately the lesson today is the same as it was in 2008. Trusting your system security to code that is inherently and demonstrably untrustworthy is foolish at best. Unlike some others, I still count this incident as a demonstration of the virtue of open source - the evidence that GnuTLS was untrustworthy has always been there, out in the open. That members of the community chose to ignore the signs is not an indication that the open source development model is weak. It’s simply an acknowledgement that, even in open source, political issues will often overrule technical merit.