Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenSSL Cleanup: Hundreds of Commits In a Week

timothy posted about 6 months ago | from the the-good-kind-of-competition dept.

Encryption 379

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.

cancel ×

379 comments

Sorry! There are no comments related to the filter you selected.

I would think (2, Insightful)

Pikoro (844299) | about 6 months ago | (#46798591)

Well, I would think that this is mostly to do with publicity. Once someone calls your software into question in a very public light, you will be more willing to go through your project with a fine toothed comb and clean up all that old cruft you've been meaning to clear out.

This is not a sign of inherent insecurity, but one of obvious house cleaning.

Re:I would think (5, Informative)

Anonymous Coward | about 6 months ago | (#46798619)

Note that OpenSSL isn't part of the OpenBSD project. It's a separate project.

Re:I would think (-1)

Anonymous Coward | about 6 months ago | (#46798621)

Kinda like closing the barn door after all the horse are out.

Better late than never I guess.

Re:I would think (2, Insightful)

Anonymous Coward | about 6 months ago | (#46798669)

Kinda like closing the barn door after all the horse are out.

The comparison is not even remotely valid. Even if, what would your suggestion be? They do nothing about it? They proceed at the pace they have already? That they go on like nothing has happened? They take this seriously and act accordingly.

You do not need to mock them for a mistake. Or are you so perfect that you never have made a coding mistake? ROFL

Better late than never I guess.

Yes, better late than never. If they had known about the bug earlier I bet money on they would have fixed it earlier. Bad press or not.

Re:I would think (-1)

Anonymous Coward | about 6 months ago | (#46798761)

Theo, is that you?

And yes, I am perfect. Thanks for asking.

Re:I would think (2)

chris.alex.thomas (1718644) | about 6 months ago | (#46798775)

disagree: mocking people for making mistakes that they should know better is a way to help that person permanently try harder to avoid those mistakes in the future.

with failure, comes mockery, especially if you are skilled and it should never have happened.

mistakes can't go unpunished, even if the person doing the punishing is yourself, you can't tell other people to back off, you deserve it, sit back and take it on the chin and try harder next time otherwise people won't have any reason to try, because the penalty for failure is barely noticeable.

Re:I would think (-1, Flamebait)

Spiked_Three (626260) | about 6 months ago | (#46798929)

You are right, it is nothing like closing the door after the horses got out, it is more like closing the door after all the horses are dead.

Multiple eyes on code, security, these are things that are great about open source, except they aren't. This is a prime example of how bugs get through anyhow, major bugs. So it is now shown beyond a shadow of anyones doubt, open source is NOT superior in these respects.

Design and QA are 2 more things open source does not do anywhere near as well as closed source. It doesn't take much of a leap to understand open source it what it is, a free less than ideal solution that is NO competitor to closed source.

Re:I would think (5, Insightful)

Kythe (4779) | about 6 months ago | (#46798967)

All of what you say may be correct. But one major bug doesn't prove it. I do recall seeing quite a few life-or-death bugs in closed source projects over the years -- including stuff that most people use. So it's unclear to me whether you have additional evidence to support your statement, or are simply saying something self-serving.

There's a reason why the plural of anecdote isn't evidence.

On a related note, there's a reason why most of the most prominent security researchers seem to prefer open access to source code. I have yet to hear any of them change their mind over this bug.

Re:I would think (5, Insightful)

Antique Geekmeister (740220) | about 6 months ago | (#46798971)

> Multiple eyes on code, security, these are things that are great about open source, except they aren't. This is a prime example of how bugs get through anyhow, major bugs. So it is now shown beyond a shadow of anyones doubt, open source is NOT superior in these respects.

Really, no. The horses are still pulling plows, and carts, and carriages, every day. The library is still in use in operating systems world wide.

This is more visiting the barn that had horses stolen and making sure the locks and doors actually work the way they should before it's trusted at all again.

Open Source is still software development (3, Interesting)

hessian (467078) | about 6 months ago | (#46799071)

Multiple eyes on code, security, these are things that are great about open source, except they aren't. This is a prime example of how bugs get through anyhow, major bugs. So it is now shown beyond a shadow of anyones doubt, open source is NOT superior in these respects.

Our modern malady is to look at methods, not histories.

Great software comes from great leadership and good-to-great talent. But mostly, it involves someone having a good idea and following it through.

Sometimes, that's a single programmer (Bill Atkinson). Most commonly, it's a group that needs a leader.

The quality of that leader then determines the quality of the product. But both industry and open source find this idea terrifying.

Industry would prefer to avoid this and promote exchangeable, replaceable cogs to the position of program/project manager. These people tend to be aggressive and thoughtless and produce gunk software.

Open source would prefer to avoid it because the big secret in open source is that people do what they want to do, not what needs doing. This is why products usually have the "fun, interesting parts" done but lag behind in the stuff no one finds thrilling, including finishing the boring parts of the code, debugging, documentation, etc.

Leadership is essential. The difference is that in open source, you can't fire people, so you can't tell them what to do.

Re:I would think (1)

BiIl_the_Engineer (3618863) | about 6 months ago | (#46799083)

This is a prime example of how bugs get through anyhow, major bugs.

It happens with proprietary software, too. The difference is, people who aren't part of the organization making the code don't have much of a chance of checking out the source code. Wow, that's so much better!

Re:I would think (1)

nyt (18341) | about 6 months ago | (#46798653)

OpenSSL is not part of the OpenBSD project.

Re:I would think (1)

kthreadd (1558445) | about 6 months ago | (#46798745)

It is now, considering that the most active development is going on there. Will probably have to change to another name though.

Re:I would think (5, Informative)

badger.foo (447981) | about 6 months ago | (#46798661)

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.

Re:I would think (2)

smash (1351) | about 6 months ago | (#46798747)

Yup. I can't believe that there were such dodgy trade-offs made for SPEED (at the expense of code readability and complexity) in openSSL. SSL/TLS is one of the things I don't care about speed on. I want a secure connection - i'll take my ADSL running like a 28.8k modem if that's what it takes.

Re:I would think (-1)

AlterEager (1803124) | about 6 months ago | (#46798819)

The problem is not your ADSL running like a 28,8k modem.

The problem is Google's servers exploding in a nuclear fireball.

Re:I would think (-1)

Anonymous Coward | about 6 months ago | (#46798837)

That's not the correct way to spin hyperbole. Next time try: "Google's servers exploding in a nazi nuclear fireball"

Re:I would think (4, Informative)

Halo1 (136547) | about 6 months ago | (#46798911)

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

That code is not dead, there are actually still people using OpenSSL on OpenVMS and actively providing patches for it: https://www.mail-archive.com/o... [mail-archive.com]

Re:I would think (5, Interesting)

khchung (462899) | about 6 months ago | (#46798757)

Well, I would think that this is mostly to do with publicity. Once someone calls your software into question in a very public light, you will be more willing to go through your project with a fine toothed comb and clean up all that old cruft you've been meaning to clear out.

This is not a sign of inherent insecurity, but one of obvious house cleaning.

And how many bugs and vulnerabilities will they put in with such high volume of commits in such short time?

- If a change is only "house cleaning" which is unrelated to security, why do it in such a rush?

- If a change is security related, and obviously needed, then why wasn't it made earlier? Didn't that make a mockery of all the "many eyes" arguments oft touted in favor of Open Source?

- 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 matter how you look at it, making so many changes in a rush is not a good idea.

Re:I would think (5, Informative)

serviscope_minor (664417) | about 6 months ago | (#46798815)

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.

Re:I would think (5, Insightful)

InvalidError (771317) | about 6 months ago | (#46798843)

From the looks of it, many of the (potential) bugs in OpenSSL are caused by the use of a custom memory allocation scheme instead of a standard C allocator. Removing the custom memory management in favor of standard memory management alone implies dozens if not hundreds of relatively trivial code changes to all the places where the custom (de-)allocator get used. In the process of tracking down all of these, they come across stuff that does not look right and fix it while they are already in there.

As for why so many bugs, "so many eyes" only works if you still have tons of people actively participating in the project's development. At a glance, it seems like the OpenBSD guys are saying the OpenSSL project was getting stale. Stale projects do not have anywhere near as many eyes going through their code nor as many people actively looking for potential bugs to fix before they get reported in the wild.

In short: OpenSSL was long overdue for a make-over.

Re:I would think (2)

causality (777677) | about 6 months ago | (#46798999)

As for why so many bugs, "so many eyes" only works if you still have tons of people actively participating in the project's development. At a glance, it seems like the OpenBSD guys are saying the OpenSSL project was getting stale. Stale projects do not have anywhere near as many eyes going through their code nor as many people actively looking for potential bugs to fix before they get reported in the wild.

Yes the "logic" used by many in this thread is specious at best.

Premise: when there are many eyes looking at open source, it leads to more bugs getting fixed.

Faulty reasoning (of too many people): this project didn't have many eyes, therefore the premise is false. Herp derp.

Correct reasoning: when the condition of "many eyes" was met, the premise is shown to be true.

Conclusion: some people dislike Open Source for ideological reasons and saw this as a chance to take cheap shots at it and show everyone how clever they are ... and failed because of faulty reasoning. Just like what you see in politics - if you happen not to like something, it must be BAD!! and cannot possibly have merits that you simply don't value.

Re:I would think (2)

gbjbaanb (229885) | about 6 months ago | (#46799033)

From the looks of it, many of the (potential) bugs in OpenSSL are caused by the use of a custom memory allocation scheme instead of a standard C allocator

not necessarily - when I saw a commit that said "removed use after free" (ie still using a structure after it had been freed) then you've got to think the code is just generally sloppy.

Re:I would think (2)

monkey999 (3597657) | about 6 months ago | (#46799045)

The irony behind the argument that "many eyes" didn’t work here, is that the code was only tested so thoroughly [readwrite.com] because it was open source. We've no idea how many bugs like heartbleed there might be in proprietary libraries that simply hasn't been found yet (outside the NSA)

Re:I would think (5, Interesting)

Richard_at_work (517087) | about 6 months ago | (#46798763)

As the other poster says, OpenSSL isn't an OpenBSD project - what is going on here is a full blown fork of OpenSSL by the OpenBSD team, who are putting their money where their mouths are because when the heartbleed bug came out it was noted that the issue could have been mitigated on OpenBSD if the OpenSSL team had used the system provided memory allocation resources.

So this is less OpenSSL and much more OpenBSD SSL being created.

Re:I would think (5, Insightful)

stor (146442) | about 6 months ago | (#46798861)

IMNSHO this is more about the OpenBSD folks doing what they do best.

I sincerely respect their approach to programming, especially with regards to security: rather than just introduce security layers and mechanisms they program defensively and try to avoid or catch fundamental, exploitable mistakes.

Hats off to the OpenBSD folks.

Regression testing? (0)

Anonymous Coward | about 6 months ago | (#46798599)

Are they sure the weird code isn't meant to fix weird bugs?

code review time! (1)

Anonymous Coward | about 6 months ago | (#46798603)

Who's been reviewing these 250 commits for even more bugs?

Re:code review time! (1)

Anonymous Coward | about 6 months ago | (#46798691)

Talented developers with expertise in security - i.e. other OpenBSD developers.

Re:code review time! (1)

Anonymous Coward | about 6 months ago | (#46798771)

Yeah, Top... Men.

The same top men studying the Lost Ark of the Covenant in Raiders apparently. You don't need to worry your little head about it. They have top men working on it. Move along.

Re:code review time! (4, Funny)

St.Creed (853824) | about 6 months ago | (#46798803)

The NSA, obviously.

Next question please.

Good Job Guys (1)

flyneye (84093) | about 6 months ago | (#46798611)

Lotta work,good reason, good job guys.

WTF IS KNA TLA? (1)

Anonymous Coward | about 6 months ago | (#46798613)

Thanks editors.

KNF - Kernel Normal Form [wikipedia.org]

I assume this is an R&D exercise? (3, Insightful)

Anonymous Coward | about 6 months ago | (#46798615)

Because "over 250 commits" in a week by a third party to a mature security product suggests either a superhuman level of understanding or that they're going to miss a lot of the implications of their changes.

Re:I assume this is an R&D exercise? (5, Insightful)

Anonymous Coward | about 6 months ago | (#46798665)

The fact that these 250 commits are mostly coding-style changes was conveniently hidden behind the acronym "KNF". Honi soit qui mal y pense!

Merged back or fork? (2)

dutchwhizzman (817898) | about 6 months ago | (#46798633)

From what I understood earlier, this will be a fork of the official OpenSSL release, or will all these patches be incorporated in "generic" OpenSSL and not just the OpenBSD implementation?

Re:Merged back or fork? (4, Informative)

badger.foo (447981) | about 6 months ago | (#46798679)

The work by the OpenBSD developers happens in the OpenBSD tree. Whether or not the OpenSSL project chooses to merge back the changes into their tree is yet to be seen. Given the activity level in the OpenSSL tree lately I find it more likely that the primary source of a maintained open source SSL library shifts to the OpenBSD project. To the extent that portability goo is needed it will likely be introduced after the developers consider the code base stable enough.

Re:Merged back or fork? (3, Insightful)

toonces33 (841696) | about 6 months ago | (#46798715)

Well they seem to be ripping out a lot of things related to portability, so my guess is that this new effort is a dead end that the rest of us will never see. All the OpenBSD developers care is that the thing works on OpenBSD.

Re:Merged back or fork? (3, Interesting)

petermgreen (876956) | about 6 months ago | (#46798735)

We may see a model similar to openssh where the core code in openbsd is kept free of "portability goop" and then a seperate group maintains a "portable" version based on the openbsd version.

Re:Merged back or fork? (4, Informative)

smash (1351) | about 6 months ago | (#46798751)

Not necessarily. They are ripping out a lot of crap, much of which is portability done badly. The priority, it appears to is get back to a minimalist, secure code base, and then re-port it (to selected, actually used architectures, not big-endian x86 for example - which was some of the code removed) as time permits.

Re:Merged back or fork? (0)

Anonymous Coward | about 6 months ago | (#46798767)

Yeah, if you're worried about using OpenSSL on VMS or Windows 98, sure.

Re:Merged back or fork? (0)

Anonymous Coward | about 6 months ago | (#46798949)

Yeah, if you're worried about using OpenSSL on VMS or Windows 98, sure.

Those are the only platforms I use, you insensitive clod.

Re:Merged back or fork? (4, Informative)

serviscope_minor (664417) | about 6 months ago | (#46798825)

Well they seem to be ripping out a lot of things related to portability, so my guess is that this new effort is a dead end that the rest of us will never see.

No: OpenBSD is a straightforward, clean, modern unix.

They are ripping out all the stuff for portability to ancient unix and even long obsolete non-unit platforms.

Much software compiles cleanly on OpenBSD, FreeBSD and Linux. If they do it well---and every interation I've had with OpenBSD code indicates that they will---it will e very easy to port it to Linux (and other modern operating systems).

I expect what will happen is they will get it working on OpenBSD with enough API compatibility to compile the ports tree. Once it begins to stabilise, I expect people will maintain branches with patches to allow portability to other operating systems.

Historical portaility causes hidoeus rot. I know: i've had it happen to me. There are old systems out there so perverse, they poison almost every part of your code. I think a semi-clean break like this (keep the good core, mercilessly rip out historically accumulated evil) is necessary.

Re:Merged back or fork? (0)

Anonymous Coward | about 6 months ago | (#46798697)

They're focusing on getting it right for now - questions about the future and exactly what form the code will take aren't being worried about until the code is in good shape.

it's a good effort (5, Interesting)

tero (39203) | about 6 months ago | (#46798647)

Right now, I think the team is mostly focused on having "something usable" in OpenBSD and I doubt they care too much about anything else outside their scope.

Having said that - forking OpenSSL to something usable and burning the remains with fire is a great idea, however there is considerable risk that the rush will cause new bugs - even though right now those commits have been mostly pulling out old crap.

Fixing the beast is going to take a long while and several things will need to happen:
- Upstream hurry to put more crap into the RFC needs to cease for a while. We don't need more features at the moment, we need stability and security.
- Funding. The project needs to be funded somehow. I think a model similar to Linux Foundation might work - as long as they find a suitable project leads. But major players need to agree on this - and that's easier said than done (who will even pull them to the table?)
- Project team. Together with funding, we need a stable project team. Writing good crypto code in C, is bloody hard, so the team needs to be on the ball - all the time. And the modus operandi should be "refuse features, increase quality". Requires a strong Project Lead.
- Patience.. fixing it is a long process, so you can't go into it hastily. You need to start somewhere (and here I applaud the OpenBSD team), but to get it done, assuming that above is in place - expect 1-3 years of effort.

Re:it's a good effort (2)

aliquis (678370) | about 6 months ago | (#46798709)

refuse features, increase quality

Excuse me while I smile and laugh inside while I think about the different projects and their view or behavior in that regard.

Re:it's a good effort (0)

Anonymous Coward | about 6 months ago | (#46798795)

Having said that - forking OpenSSL to something usable and burning the remains with fire is a great idea, however there is considerable risk that the rush will cause new bugs - even though right now those commits have been mostly pulling out old crap.

While the code is in OpenBSD CVS, it may not become the default right away.

5.5 is scheduled to come out on May 1, and it's obviously too late for that. They'll probably go with 5.6 on November 1 at the earliest.

These are the folks that make OpenSSH: they generally know what they're doing.

Re:it's a good effort (0)

Anonymous Coward | about 6 months ago | (#46798817)

> Writing good crypto code in C, is bloody hard

Which is the reason for not doing it in C, when there is plenty of alternatives.

Re:it's a good effort (1)

sqlrob (173498) | about 6 months ago | (#46799035)

There are plenty of alternatives that are present in many embedded devices?

Quatity is not quality (0)

houghi (78078) | about 6 months ago | (#46798651)

I do not care if there are 50 or 250 or 5000 commits. I want 1 that makes it secure. If anything, these commits will open a new insecurity, because they are so numerous.

And if there are that many, would a new start not be better?

Re:Quatity is not quality (4, Insightful)

drolli (522659) | about 6 months ago | (#46798711)

I cant talk for C, but in Java the tools which warn you about potentially dangerous constructs are great (e.g. Sonar). You can easily identify many *suspicous* contructs and change them to something more safe. 250 commits per week with 4 devs on a moderatly sized project do not see much to me, much at the "quality" and not the "quantity" side.

What annoys me is that - with all due respect - the companies which embed openssl in their products could have done a review of the code for quality. To me it seems that it's a fundamental library.

Re:Quatity is not quality (3, Insightful)

aliquis (678370) | about 6 months ago | (#46798719)

And if there are that many, would a new start not be better?

How about no?

Also I don't see why lots of fixes would necessarily mean poor fixes. They likely do what they feel is obvious fixes / stuff they consider wrong. Or something such. What do I know really.

Possibly they know what they are doing.

Re:Quatity is not quality (3, Informative)

carlhaagen (1021273) | about 6 months ago | (#46798731)

It seems you're not familiar with the process of software development. You just don't issue one single commit containing a billion changes. It's a step by step process, for several reasons, most importantly the mechanic and iterative process of searching for bugs.

Re:Quatity is not quality (2, Informative)

Anonymous Coward | about 6 months ago | (#46798787)

A new start would introduce far more issues, so a major cleanup can be preferable.

Some of this code is 18 years old. There are whole swathes of code that is depreciated. Cleanup and standardisation of layout helps. Removal of things like the VAX, Windows, obsolete compilers.... Already with the KNF and cruft being removed there are things being seen and some commits being made to remove scary things.

Seriously, read some of those commits and you will see that this /will/ help wrangle it into a far more secure state.

Coding style fixes are "news" for nerds? (0, Informative)

Anonymous Coward | about 6 months ago | (#46798657)

This must be one of the most ridiculous Slashdot stories ever!
Most of these commits are coding style "fixes": Example [estpak.ee] .

Just again proof that these OpenBSD guys are nothing but a bunch of bigmouths. Incidently, the bug in OpenSSH ca. 10 years ago was the only time a machine of mine goot rooted.

Re:Coding style fixes are "news" for nerds? (0)

Anonymous Coward | about 6 months ago | (#46798721)

Please. Everyone got rooted that one time 10 years ago. SSH was so famously vulnerable back then it even appeared in a movie.

Re:Coding style fixes are "news" for nerds? (1)

smash (1351) | about 6 months ago | (#46798773)

Not me. Exposing ssh to the entire internet unless required = retarded.

Re:Coding style fixes are "news" for nerds? (0)

Anonymous Coward | about 6 months ago | (#46799017)

Openssl is used for a lot more than just ssh.

Coding style fixes ARE news for nerds. (0)

Anonymous Coward | about 6 months ago | (#46798727)

If Apple has taught us anything, it's that bad coding style can cause a lot of problems. Clean up your desk before you work buddy.

I'm going to ignore the comment about the bug in OpenSSH because you obviously weren't running it on OpenBSD; but rather one of the distro-maintained packages that are so souped up in "patches".

Re:Coding style fixes are "news" for nerds? (4, Informative)

K. S. Kyosuke (729550) | about 6 months ago | (#46798853)

Most? [estpak.ee] You've linked one big commit fixing a lot of style problems. Other than that, I see missing checks being added and strange code being fixed all over the place in a lot of commits. Aren't you twisting the reality just a little bit?

Too specific? (1)

Anonymous Coward | about 6 months ago | (#46798659)

Without looking at the code or the commits, I'm guessing that one man's weird layers of abstraction are another man's portability requirements...

This isn't fixing SSL (4, Informative)

beezly (197427) | about 6 months ago | (#46798671)

The article doesn't make it completely clear that this doesn't have much to do with the fixing problems in OpenSSL.

Commits to the true OpenSSL source can be seen through the web interface at https://github.com/openssl/ope... [github.com] . What the article is talking about is tidying up the version that is built in to OpenBSD. Not that that isn't worthwhile work, but it's unlikely to fix many hidden problems in OpenSSL itself, unless the OpenBSD devs find something and hand it back to the upstream.

Re:This isn't fixing SSL (1)

beezly (197427) | about 6 months ago | (#46798675)

By "fixing SSL" I meant "fixing OpenSSL". Duh! :(

Re:This isn't fixing SSL (1)

badger.foo (447981) | about 6 months ago | (#46798685)

Take a look at the actual commits. Quite a bit of 'KNF', but far from all of it. There's a lot of bugs removal that will benefit everyone.

Are they still running it through Coverity ? (3, Interesting)

bheading (467684) | about 6 months ago | (#46798677)

OpenSSL is on the list of projects scanned by Coverity [coverity.com] .

I wonder why exactly Coverity did not catch the heartbleed bug. Most likely, the scan wasn't set up to deal with OpenSSL's use of it's own internal heap management routines. That's something that I would have thought should be fixed right away.

Re:Are they still running it through Coverity ? (-1)

Anonymous Coward | about 6 months ago | (#46798769)

alternatively, coverity sucks donky balls, and we're all tired of the their smarmy
sales critters infecting open source events.

Re:Are they still running it through Coverity ? (5, Informative)

Anonymous Coward | about 6 months ago | (#46798793)

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

Re:Are they still running it through Coverity ? (1)

bheading (467684) | about 6 months ago | (#46799081)

Ah I should have checked that. Thanks.

Re:Are they still running it through Coverity ? (0)

Anonymous Coward | about 6 months ago | (#46798807)

I believe that Coverity did not find the defect, since it was external information that was tainted.

Using an in-house version, they were able to modify their scan to detect the issue [coverity.com]

Re:Are they still running it through Coverity ? (3, Insightful)

ledow (319597) | about 6 months ago | (#46798875)

Because static analysis cannot catch all problems.

It's as simple as that.

Their "fix" is to mark all byte-swapping as "tainted" data... basically it's a heuristic they've decided on, not proof of foul play (which is almost impossible to get on static analysis of someone else's code).

Relying on things like Coverity to find everything will always end in disappointment. What you do is fix what it finds, when and where it's a problem. The fact is, they simply had no way to detect this issue whatsoever, but fudged one for now. The next "big hole" will be just the same.

All due to them, Coverity is a very powerful and helpful tool. But you can't just give the impression that because it's been "scanned by Coverity" (or Symantec Antivirus, or Malwarebytes, or ANYTHING AT ALL WHATSOEVER) that's it's "safe". That's just spreading false confidence in duff code.

They don't pay attention to Coverity (0)

Anonymous Coward | about 6 months ago | (#46799027)

"Coverity used to, and perhaps still do, run scans of OpenSSL, which we
had (have?) access to. I used to look at them and fix relevant ones,
but got irritated with the false positive level in the end.

If Coverity were interested in fixing their bugs, I might get
interested in looking at their reports again.[1]"

Having used Coverity in a commercial setting, he's absolutely incorrrect: Coverity flags *icredibly subte* problems, which you may have to think about for a while before you figure out why the construct is FUBAR. The false positive rate is incredibly low. I mean, astonishingly low, really.

[1]http://openssl.6102.n7.nabble.com/Coverity-coverage-of-OpenSSL-td42651.html

But is it that easy? (1)

swb (14022) | about 6 months ago | (#46798689)

For a handful of developers to just "run through the code" and fix everything that easily? And do it quickly, without introducing other bugs?

I am not a developer, but I can remember writing software whether for BASIC, Pascal or Perl and going back to fix or extend something and seeing stuff and saying "Why did I do it that way?" and making changes that I'm not honestly sure were "improvements" except for they seemed like improvements at the time even though they may have created new bugs.

I don't know anything about the internals of OpenSSL so maybe it is that easy, but it makes me wonder why it hasn't been done before. But I suspect it is complex and having a lot of people committing changes all at once seems like it runs the risk of working a cross-purposes without a lot of coordination (which, maybe they have).

Re:But is it that easy? (0)

Anonymous Coward | about 6 months ago | (#46798713)

They haven't fixed everything, they've just scratched the surface. A lot of these are style fixes - the developers are anticipating another 6 or 7 weeks of dedicated work to fix most of the actual problems.

Re:But is it that easy? (1)

gbjbaanb (229885) | about 6 months ago | (#46799069)

The main part of this s to tidy things up. One commit removes a load of custom functions and replaces it with a single include of unistd.h - which is really removing stuff put in way, way back because a platform didn't have unistd back then. Similarly, they get rid of weird stuff that is more standardised today.

I think the real code auditing and fixing will happen later.

woolyeyed hoodwinking festival ending (-1)

Anonymous Coward | about 6 months ago | (#46798693)

we are won http://www.youtube.com/results... [youtube.com]

And Linus still does nothing... (0, Informative)

Anonymous Coward | about 6 months ago | (#46798723)

...but throw accusations and insults about monkeys and too hard focus on security - while still being happy someone else is doing the good work.

Testing and validation is what's needed (1)

putaro (235078) | about 6 months ago | (#46798725)

Code fixes are all fine and well but where the real thought needs to be going is how to verify these protocols. The basic problem with security is that "working" doesn't mean "secure". Most people focus on testing for "working" and given the bugs that have shown up in OpenSSL and its cousin in the last month or so, the problem is not that they don't work (that is, interoperate and transmit data) but that they have corner cases and API holes that are major security concerns. Some real thought needs to be put into the testing of secure systems and how to verify that they not only "work" but are actually secure.

Re:Testing and validation is what's needed (0)

Anonymous Coward | about 6 months ago | (#46798755)

Are you new around these parts? I'd say the OpenBSD is the most experienced and qualified developer team on the planet in regards to software security. They have an unquestionable track record of developing towards "secure" instead of "it compiles, let's ship it".

Re:Testing and validation is what's needed (2)

smash (1351) | about 6 months ago | (#46798781)

Agreed. However fixing obviously brain damaged code is a start.

I want to know... (1)

msauve (701917) | about 6 months ago | (#46798743)

What's the tag for the NSA guy charged with putting holes back in? I'd like to follow how he's doing it.

Seriously, it took 2 years to find the big one after it was committed. How much vetting have each of these 250 commits undergone? Who's watching the watchers?

Re:I want to know... (2)

satch89450 (186046) | about 6 months ago | (#46799085)

  1. clean up
  2. tighten up
  3. inspect
  4. test
  5. field test

In a clean-up operation, you don't vet each change, especially when the change is reformatting instead of a real code change. It's clear from the commits I've looked at that the people doing this are working to eliminate the cruft that inevitability builds up in any project as it matures. See http://en.wikipedia.org/wiki/C... [wikipedia.org] -- you take baby steps, and check your work as you go.

In the process of clean-up, of re-factoring, one may find and fix subtle bugs, such as the missing bounds check that is at the heart of, um, heartbleed. Elimination of the custom memory management in favor of the native OS code (particularly when the OS takes pains to clear out free memory -- which would have stopped heartbleed cold on some platforms) decreases the complexity of the code, and -- arguably -- makes it easier to read. Replacing clumsy code with better-crafted code that does the same thing but far more clearly makes it easier to read. Removing out-dated portability hacks removes a lot of chaff so the wheat is easier to see. But you can't do this all in one commit and expect not to stub your toe.

Repeat as necessary

When the clean-up tighten-up passes are complete, and the cruft is mostly gone, the developers then need to comb through the code looking for issues missed in the first pass, and brokenness caused by unfortunate re-factoring. It happens. Also, error patterns will pop up when the code is reformatted to a single standards. Further, because people are looking not just at syntactic content at this point, but semantic content, comments can be added to document any awkward or un-obvious constructs.

An integral part of examining the code is the development of test cases for the scaffolded version of the code. This needs to check for conformance to the RFC, and also explore what happens with intentionally malformed packets. This is the crucial step which appears to have been missing or incomplete with the pre-heartbleed OpenSSL code. Code inspection will catch stuff; test cases will expose those problems that were missed during the inspection. This process assumes that the program is structured in such a way that scaffolding is possible from a library of the code base, so each function, or small set of functions, can be tested in isolation. I find, in my own work, that I typically write several thousand lines of code during development to ensure that each major function works as expected -- and that code lives on as scaffolded test code so that when I make a change I can test it against a known set of test cases. (Sometimes, you have to change the test , or add tests, because the function changes or a bug sneaks through, but then you have a check-and-balance to minimize issues.)

You ask "Who is watching the watchers?" The answer is an easy one: as usually happens, management will work to solve yesterday's problems. I fully expect, when the work is finished, that the security researchers will pounce on the "new and improved OpenSSL" to find the bugs and holes that didn't get fixed during the current round. They struck gold once -- and like most gold bugs, they will mine the same hill until they go broke, just like the 49ers did.

One interesting effect is that Coverity [coverity.com] made improvements in their code-scanning product. (See comments above this one.) The net effect is that all the products scanned by Coverity products will benefit. Which further answers your question: we now have improved computer watchers, too.

The commits are funny into themselves. (4, Informative)

strredwolf (532) | about 6 months ago | (#46798777)

A Tumblr site popped up a few days ago called OpenSSL Valhalla Rampage [opensslrampage.org] . The blogger there is going through all the commits and posting the juicy funny comments there. This includes killing... and rekilling... VMS support (which reminds me of Maxim 37: there is no such thing as overkill... [ovalkwiki.com] ), stripping out now-stupid abstractions and optimizations of the unoptimizables, and more.

Re:The commits are funny into themselves. (1)

St.Creed (853824) | about 6 months ago | (#46798839)

I love this :)

My favorite comment:

now that knf carpet bombing is finished, switch to hand to hand combat. still not sure what to make of mysteries like this: for (i = 7; i >= 0; i—) { /* increment */

Re:The commits are funny into themselves. (2)

Bill Dimm (463823) | about 6 months ago | (#46798917)

I'm wondering what is supposed to be mysterious about that code. The "/* increment */" comment seems to apply to the code inside the loop, not what is being done to the i variable, so I don't think that's it. Is it because the loop goes from 7 down to 0 instead of the other way around? I remember reading a programming book back in the 80's that advocated doing that for better speed since the assembly code generated to compare to 0 was faster than comparing to some other integer (which seems to no longer be the case, and I suspect could even cause cache misses for a bigger loop, although I don't know enough about how CPUs fill the cache to know for sure).

Re:The commits are funny into themselves. (3, Informative)

Megol (3135005) | about 6 months ago | (#46799091)

I'm wondering what is supposed to be mysterious about that code. The "/* increment */" comment seems to apply to the code inside the loop, not what is being done to the i variable, so I don't think that's it. Is it because the loop goes from 7 down to 0 instead of the other way around? I remember reading a programming book back in the 80's that advocated doing that for better speed since the assembly code generated to compare to 0 was faster than comparing to some other integer (which seems to no longer be the case, and I suspect could even cause cache misses for a bigger loop, although I don't know enough about how CPUs fill the cache to know for sure).

Comparing to zero is faster in most architectures and still is a valid optimization. There shouldn't be any problems with cache misses either, if the architecture does stream detection it should do it for reversed streams too and if it doesn't (only detecting actual misses) doing it in reverse isn't a problem.

Re:The commits are funny into themselves. (0)

Anonymous Coward | about 6 months ago | (#46798927)

ovalkwiki's certificates are messed up, heh.

How many new bugs (0)

Anonymous Coward | about 6 months ago | (#46798785)

were introduced with all these commits?

NSA (1)

Lehk228 (705449) | about 6 months ago | (#46798799)

which one of the patches is the new NSA subversion?

Thank You (5, Insightful)

Anonymous Coward | about 6 months ago | (#46798827)

just a simple thank you to all the coders out there who donate of their skills and time to produce this and other very important software, for free folks! Thank You for making the world a better place

No Good. (0)

Anonymous Coward | about 6 months ago | (#46798859)

It's not good that there is this much that can and should be changed.
It's not good that a fundamental project like this seems to not have had this kind of code audit before.
It's not good that the massive rush to update has likely resulted in a 'new' version being widely deployed with bugs (see above).
It's not good that security testing clearly hasn't been done before, and now there is a lot of churn... which will need to be tested also.
It's not good that people will say the above falsifies one of the fundamental arguments for OpenSource.
It's not good that the newly deployed versions have the bugs Theo and team are fixing, and the commits point at the bugs like a bullseye.

Of course, if it wasn't open, it could not be fixed. That doesn't excuse the state it is in. Massive Fail.

Pretty funny (0)

Anonymous Coward | about 6 months ago | (#46798869)

how after the event of Heartbleed the open-source community actually give a damn about contributing to their favourite OSS project is when the realization hits home that what they got for free, put nothing into, and take everything away from may not be foolproof in the immediate short-term - then, they suddenly start to care about the projects.

Why can't there be actions like this every day for all projects, the "I'll fix it when it finally breaks" attitude is damaging and does about as much good as companies like Microsoft. A real shame this only happens when something happens which might take their free lunch away from them.

What's with the @s? (0)

Anonymous Coward | about 6 months ago | (#46798877)

Maybe I'm too old now to be current, but wtf is up will all the @ signs? I.e. beck@, etc? Is it the first part of their email address? If so, why do we need their email addresses in the article?

Worst thing possible (1)

Anonymous Coward | about 6 months ago | (#46798881)

Seriously, could they screw the pooch any harder than they are right now?

Hundreds of commits, after just *DAYS* of testing? I've never seen a faster or more reckless release cycle for code changes, ever.

This just tells me they are putting in hundreds of basically untested code changes, which is what got us into this mess in the first place.

OpenSSL is dead to me now.

Number of commits is meaningless (2)

Pop69 (700500) | about 6 months ago | (#46798885)

Quantity doesn't equal quality

"axing it up into shape"? (0)

Anonymous Coward | about 6 months ago | (#46798895)

I've been on this planet for four decades and I've never heard this idiom before.

KNF can wait (1, Insightful)

gatkinso (15975) | about 6 months ago | (#46798899)

It is most annoying trying to hunt bugs while wading thru massive diffs caused by formatting changes.

Deal with that later.

Testing? (0)

Anonymous Coward | about 6 months ago | (#46798993)

I'd feel better if this was an article about the rigorous testing regime being applied to OpenSSL...

list of changes (5, Informative)

monkey999 (3597657) | about 6 months ago | (#46799001)

A summary of the changes is here [undeadly.org] :

Changes so far to OpenSSL 1.0.1g since the 11th include:

  • Splitting up libcrypto and libssl build directories
  • Fixing a use-after-free bug
  • Removal of ancient MacOS, Netware, OS/2, VMS and Windows build junk
  • Removal of “bugs” directory, benchmarks, INSTALL files, and shared library goo for lame platforms
  • Removal of most (all?) backend engines, some of which didn’t even have appropriate licensing
  • Ripping out some windows-specific cruft
  • Removal of various wrappers for things like sockets, snprintf, opendir, etc. to actually expose real return values
  • KNF of most C files
  • Removal of weak entropy additions
  • Removal of all heartbeat functionality which resulted in Heartbleed

See [twitter.com] also [freshbsd.org] :

Do not feed RSA private key information to the random subsystem as entropy. It might be fed to a pluggable random subsystem.... What were they thinking?!

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.

Hey - Thanks OpenSSL Contributors (5, Insightful)

bokmann (323771) | about 6 months ago | (#46799053)

With all the other tripe on this thread, I thought it necessary to say this loud and clear:

Hey OpenSSL Contributors - thanks for your hard work on OpenSSL, and thanks for the hard work under this spotlight cleaning this up.

Any serious software engineer with a career behind them has worked on projects with great source code, bad source code, and everything in between. It sounds like OpenSSL is a typical project with tons of legacy code where dealing with legacy is lower priority than dealing with the future. Subtracting out all the ideological debate and conspiracy theories, please realize there are plenty of 'less noisy' people out there who appreciate everything you're doing. And even more who would appreciate it if they understood the situation.

Its now time for companies who depend on OpenSSL (and other projects) to realize that Open Source software can lower their development costs, but some of that savings needs to be put back into the process or we will all suffer from "the tragedy of the Commons".

Don't leave it to one or a few people (0)

Anonymous Coward | about 6 months ago | (#46799079)

Whatever they do to OpenSSL, please don't leave it to one or a few people. Doesn't make much sense to me, to trust just a few people, if it is supposed to be open source.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?