'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 …

[Anonymous Coward]

Still, forking the code is good

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...

[petur]

Re: Still, forking the code is good

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.

[Anonymous Coward]

Re: Still, forking the code is good

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...

[Pseudonymous Coward]

Re: Still, forking the code is good

>> 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.

[Christopher E. Stith]

Re: Still, forking the code is good

GnuTLS an the Mozilla NSS are roughly similar, competing libraries to OpenSSL.

[Bronek Kozicki]

positively surprising

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.

[AndyS]

Re: positively surprising

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?

[Bronek Kozicki]

Re: positively surprising

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.

[Michael Wojcik]

Re: positively surprising

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 format¹ 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.

¹Whatever your code-formatting question may be, mixing tabs and spaces is not the right answer.

[Anonymous Coward]

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.

[bri]

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.

[Dan 55]

Do they plan to carry on digging and peppering code with platform-specific #ifdefs everywhere? I'd have thought that linking Windows builds to a Windows pthreads library would have done most of the work for free.

[Guus Leeuw]

Re Dan 55

Dear Sir,

the linkage of code to a library *cannot ever* take care of precompilation statements in that code.

Just saying...,

Guus

[Dan 55]

Re: Re Dan 55

If the two primary platforms are POSIX platforms then it makes sense to use POSIX threads for the secondary platforms as well and link builds on secondary platforms to a pthreads library, thus reducing platform-specific code and therefore #ifdefs.

Windows has one already.

[Anonymous Coward]

Support the OpenBSD team

The timing is about right for the OpenSSL team to take the cleaned up code that the OpenBSD team has provided through LibreSSL and start all over with their charging for support and consultation. Does that sound harsh or simply seem realistic?

[Charlie Clark]

Admission of failure

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.

[Not That Andrew]

Re: Admission of failure

True, but you need to use OpenSSL until LibReSSL is available on your platform of choice, so it's good they appear to be doing something.

[DropBear]

"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'.

[Michael Wojcik]

the thing is I care a lot more about attitude than resources

Huh. I care a lot more about the state of the code, personally. Proof of the pudding and all that.

[batfastad]

DogeSSL?

amaze much secure wow http://www.libressl.org

[btrower]

To be fair

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.

[Michael Wojcik]

Re: To be fair

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.

[Anonymous Coward]

So basically...

OpenSSL are going to branch LibreSSL now they've done a major prune and KNF - and then claim that they've done tons of work to improve the code base?