Slashdot Mirror
OpenSSL Cleanup: Hundreds of Commits In a Week
New submitter CrAlt (3208) writes with this news snipped from BSD news stalwart undeadly.org: "After the news of heartbleed broke early last week, the OpenBSD team dove in and started axing it up into shape. Leading this effort are Ted Unangst (tedu@) and Miod Vallat (miod@), who are head-to-head on a pure commit count basis with both having around 50 commits in this part of the tree in the week since Ted's first commit in this area. They are followed closely by Joel Sing (jsing@) who is systematically going through every nook and cranny and applying some basic KNF. Next in line are Theo de Raadt (deraadt@) and Bob Beck (beck@) who've been both doing a lot of cleanup, ripping out weird layers of abstraction for standard system or library calls. ... All combined, there've been over 250 commits cleaning up OpenSSL. In one week.'"
You can check out the stats, in progress.
Note that OpenSSL isn't part of the OpenBSD project. It's a separate project.
This is actually the OpenBSD developers diving in because the upstream (OpenSSL) was unresponsive. If you look at the actual commits, you will see removal of dead code such as VMS-specific hacks, but also weeding out a lot of fairly obvious bugs, unsafe practices such as trying to work around the mythical slow malloc, feeding your private key to the randomness engine, use after free, and so on.
It would look like it's been a while since anybody did much of anything besides half hearted scratching in very limited parts of the code. This is a very much needed effort which is likely to end up much like OpenSSH, maintained mainly as part of OpenBSD, but available to any takers. We should expect to see a lot more activity before the code base is declared stable, but by now it's clear that the burden of main source maintainership moved to a more responsive and responsible team.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
You don't have to wonder why. A quick search shows that they've already blogged about why Coverity didn't detect heartbleed.
http://security.coverity.com/blog/2014/Apr/on-detecting-heartbleed-with-static-analysis.html
And how many bugs and vulnerabilities will they put in with such high volume of commits in such short time?
You mean how many will they remove? They're largely replacing nasty portability hacks and unsafe constructs with safe, clean code. The chances are they'll be removing more bugs than they are adding.
Secondly, this is phase 1: massive cleanup. Once they've done that they are then planning on auditing the code.
f a change is only "house cleaning" which is unrelated to security, why do it in such a rush? -
it is security related: they can't audit the code (very overdue) until it's clean.
If a change is security related, and obviously needed, then why wasn't it made earlier?
Good question. Seurity people have been omplaining about the state of OpenSSL for years. But they've always had other day-jobs. I guess now there is the incentive.
Didn't that make a mockery of all the "many eyes" arguments oft touted in favor of Open Source?
Nope. Once the bug was noticed it was fixed very quickly: i.e. it was a shallow bug. If you think than phrase means OSS is bug free, you have misunderstood it.
- If a change is security related and non-obvious, then won't doing it in such a rush probably introduce new bugs/vulnerability into the code?
No, the code is too unclean for a lot of stuff to be obvious. They can't audit it until it is clean. There is a chance they will introduce some problems, but given the nature of the changes and the people involved it's likely they'll fix more than they introduce.
No matter how you look at it, making so many changes in a rush is not a good idea.
Seems like a fine idea to me.
SJW n. One who posts facts.
See also:
So far as all the "won't this introduce more bugs than it fixes" comments go, this is a recurring argument I have at work. I am of the "clean as you go", "refactor now" school.
Everyone else says "If it works don't fix it"(IIWDFI), "don't rock the boat" etc.
Heartbleed is what happens when the IIWDFI attitude wins. Bugs lurk under layers of cruft, simple changes become nightmares of wading through a lava flow of wrappers around hacks around bodges.
Whenever anyone says IIWDFI, remind them that testing can only find a small proportion of possible bugs, so if you can't see whether it has bugs or not by reading the code, then no matter how many test cases it passes, it DOESN'T WORK.