'I don't want to go on the cart' ... OpenSSL revived with survival roadmap The OpenSSL project, having suffered sharp criticism following the revelation of a string of serious security vulnerabilities, has published a roadmap explaining how it plans to address users' concerns. "The OpenSSL project is increasingly perceived as slow-moving and insular," the intro to the document states. "This roadmap …
Regarding SSL, FOSS software was too dependent on single library making it a meaty target making it a de facto monopoly in OSS (especially given its scope). Given the post-heartbleed info, we have already seen something vaguely similar - Microsoft before 'Trusted computing' initiative. Big chunks of code without systematic security review and with little care for secure code practice (discounting code they purchased from someone else). Microsoft however, worked systematically on improvements, while FOSS was fast asleep on its laurels.
The sole fact that there are many eyeballs to look at the code does not mean that there are some experienced ones that are inclined to do just that (and that maintainers are capable of integrating the patch, given for instance, lack of free time and other systematic inadequacies).
Creating featurewise roughly similiar, competing libraries is good, we need some alternatives with similar breadth to at least partially offset this problem and distribute the risk. Frankly, this is only one chunk of the code base of usual FOSS OS distribution. Wonder what other initiatives (hopefully not incidents) are necessary for other pieces of code usually found on FOSS system...
I don't see where the body of your post supports its title.
IMHO forking should be the last solution, the FOSS community is littered with forked and parallel produced code. In many cases they end up all having some kind of issue, and picking an implementation is choosing a tradeoff.
If possible, people should try to contribute to the existing project, and that's where the problem with OpenSSL lies: many users but not many contributors. Theo can have a big mouth and fork it, but that only shows nobody really cared or contributed, because the fork was because of the code, not the community.
There are cases where forking is good, because it is a nice defense mechanism to guarantee continuation of the code. Like the OpenOffice -> LibreOffice fork.
the OpenOffice -> LibreOffice fork.
Actually, the above is exactly an argument to avoid forking. You now have 2 products that are broadly similar, and it makes it difficult to choose. What parameters does a company need to apply to ensure it picks a package? Support? How much investment it has?
Business decisions are taken by people who have a job reducing risk. Having two nearly identical versions creates the risk of choosing the wrong one - so they go commercial (it's not their money anyway). Personally I like LibreOffice (it's UI works for me more than OpenOffice), but I met up with some people yesterday who use OOo because they have the impression it's better supported. Confusing...
>> If possible, people should try to contribute to the existing project, and that's where the problem with OpenSSL lies: many users but not many contributors. Theo can have a big mouth and fork it, but that only shows nobody really cared or contributed, because the fork was because of the code, not the community.
No, the point of the OpenBSD developers was that contributions/bug fixes were not integrated into the code by the OpenSSL maintainers, or at least not in a timely manner:
"At this point somebody pointed out that bug 2167 had been known to the OpenSSL devs for years. One line patches had been provided, but no action had been taken." --> http://www.tedunangst.com/flak/post/origins-of-libressl
That's highly incompatible with the OpenBSD way of thinking:
"Our security auditing team typically has between six and twelve members who continue to search for and fix new security holes. We have been auditing since the summer of 1996. The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better." --> http://www.openbsd.org/security.html
So they forked.
This is surprising news and I hope they sincerely mean what they write. If indeed OpenSSL sticks to the plan to remove dead code and cleanup the rest, and also to improve its processes and response times, it would be great. In fact, that is exactly what the project needs
However I would not expect publication of a timeline any time soon. I do not think it is possible to tell how long it would take to clean up the mess that the code is right now, without spending significant time studying all the dark corners there are. Which is fine - take your time, but do it right.
OpenSSL demonstrated to the world that they take the critique seriously, now they need to demonstrate that they know what they are doing. Which means hard work and is good use for the money pledged to the project so far.
Bronek, I've gathered from what I've read in various places that (on top of other propblems) the code is in a mess, and this must be true since they've just admitted it. It sounds like you've got some personal experience - have you delved into it? If so, what did you find?
I tried to use OpenSSL in my own home project, and like everyone doing it I had to read some parts of the code, because it is very poorly documented. If you do C or C++ programming for a living, reading this code will yield a stream of "WTF" because the code quality is really, really bad. I do not remember much detail, but my impression at the time coincides with what you can read on OpenSSL Valhalla Rampage now. Tons of dead code, even more useless macros, plenty of unintuitive functions incorrectly replicating functionality of C library, support for long dead platforms, everything done on unsafe pointers with fancy allocators etc. Above all, I was really bewildered that this seemed to work. Didn't have time to dig deeper beyond making my project to use it in somehow correct manner.
I've gathered from what I've read in various places that (on top of other propblems) the code is in a mess, and this must be true since they've just admitted it. It sounds like you've got some personal experience - have you delved into it? If so, what did you find?
I've spent a lot of time in the OpenSSL sources, from 0.9.8g through 1.0.1g; that includes reading the source and following various code paths through it in the debugger. Often, when you're using any sort of advanced OpenSSL functionality, the documentation is so incomplete that it's simply not clear why something isn't working the way you expect until you follow it through the code.
The source is a mess. I've described some of the problems with it in posts for other articles. The major functional divisions - the top-level split into the "crypto" and "ssl" libraries, and the "apps" and other secondary areas - are decent but too large to be of much help. The second level of functional division (areas such as ASN.1 processing, for example) help but are confusing until you're familiar with the code - e.g. the split between x509 and x509v3. Many of the higher-level abstractions are OK but there's far too much reliance on C macros and other code-hiding techniques. At lower levels, the source is typical of poorly-written C: short and meaningless variable names, convoluted control flow, unexpected reliance on side effects, and the like. And then there are the design flaws such as the rightly-maligned sub-allocator.
Frankly I don't think LibReSSL will fix most of this soon, if ever. While I respect what de Raadt and his crew have done with OpenBSD (and I've been following that since the '90s), they bring their own baggage, and they're off to an infelicitous start by beginning with the source layout, and using the vile KNF format1 in doing so. In general, they're making peephole changes - fixing specific bugs here and there in the code, rather than starting with the complete refactoring and design review that it needs. They bought a house with structural problems, faulty wiring, and leaking plumbing, and they've started by painting the walls.
1Whatever your code-formatting question may be, mixing tabs and spaces is not the right answer.
built-in support for POSIX and Win32 multithreading
Hmm, not sure how the support for Win32 multithreading sits with their aim to only target Linux and FreeBSD. Looking at the LibreSSL commits, the need to support MicroSoft's frankly wierd APIs are one of the major reasons the OpenSSL code is such a mess.
They are not weird, but different :)
Anyway, the reason is probably the fact that FOSS is heavily used also on Windows (really), there is for instance large installed base of Apache on Windows (the inroads of IIS is probably due to conversion of these sites, but I digress).
FOSS that is multiplatform and works also on Windows usually uses OpenSSL if it needs SSL functionality, because developers want as much OS independent code there as possible. From security and performance POV this is not optimal, but such is the situation.
is what the document reads like. Also, while it's nice listing the issues and the objectives it's missing the solution: when are the issues going to be addressed and who will be doing it? LibreSSL makes more and more sense: concentrate on getting the core functionality right first.
"The LibReSSL project is ongoing but there have been no updates so far, and OpenSSL might still have more resources to throw at a clean-up effort"
That may well be true, but the thing is I care a lot more about attitude than resources - and since I also happen to believe attitude doesn't really change, I'm not interested in what OpenSSL might want to do as damage control thinly disguised as 'having seen the light'.
To be fair, this project is hardly alone with respect to shaky code. A lot of code has been written by people with a good academic understanding of the subject matter, but a poor understanding of software development.
It does not help that *MOST* of the people in charge of software projects are not accomplished professional programmers. This discipline is particularly vulnerable to the Peter Principle.
By my reckoning, the skill of an artist lies not in his hands, but in his eyes. The fact that the aesthetics of so many of these projects are poor shows that people guiding development lack the necessary level of skill.
Security is especially problematic because not only do most of the people responsible for security lack the knowledge and skill to implement proper security, some are actually entirely impenetrable to reason: http://trac.filezilla-project.org/ticket/5530
If people are serious about fixing such things (I am pretty sure they are not), funding would be increased, developers would be skilled up in security, security people skilled up in programming and users made aware of the extent of the deficiency. I will not hold my breath.
Absolutely right. As I've noted before, the OpenSSL code is entirely typical of C source - both open-source projects and many proprietary ones. That's not primarily because of infelicities in the C language (though C goes out of its way to help), but because so much code is written by people who understand algorithms but not programming.
The quick-and-dirty approach to coding that typifies so much extant source code completely disregards the vast amount of research showing that maintenance is where most of your costs are, and that poorly-written code is full of bugs and security holes. Good code requires discipline and effort.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
