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.

Comments

I would think

[Pikoro]

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

[Anonymous Coward]

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

Re:I would think

[badger.foo]

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

[Anonymous Coward]

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

[kthreadd]

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

[smash]

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

[khchung]

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

[Richard_at_work]

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

[serviscope_minor]

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

[InvalidError]

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

[stor]

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.

Re:I would think

[Halo1]

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

Re:I would think

[Kythe]

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

[Antique Geekmeister]

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

Re:I would think

[causality]

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

[gbjbaanb]

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

[monkey999]

The irony behind the argument that "many eyes" didn’t work here, is that the code was only tested so thoroughly 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

[BiIl_the_Engineer]

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

[Enigma2175]

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.

But the whole heartbleed issue was caused by someone who was doing more than "half hearted scratching", he was adding an entirely new feature (heartbeats). Does anyone else think that hundreds of commits in a week is a BAD thing? It seems to me like committing that much code would make it so each change doesn't get as much of a review as it would if the changes were committed gradually. Poor review is what caused this problem in the first place, they run the risk of adding another critical vulnerability.

Re:I would think

[causality]

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.

That's the old-school view, in which one's self-esteem is based on achievement of some kind. Those who achieve little or nothing had low self-esteem and this was a principal incentive to identify one's own weaknesses and overcome them with directed effort. The extreme form is Japanese students throwing themselves off buildings (etc.) because their grades didn't quite measure up, making them nobodies.

The newer view is that everyone is a special snowflake. No matter what. The extreme form is shown by the public schools that play soccer without keeping score, because scoring implies winners and losers and that might hurt someone's feelings.

I mostly agree with you in that actions have consequences and you should accept the consequences of your own actions. Otherwise nothing really matters and there is no reason to improve yourself and you turn into one of these "perpetual victims" who never take responsibility for anything while simultaneously wondering why nothing ever changes. But that should be tempered with the fact that some mistakes are much more preventable (less understandable) than others, and as Orlando Battista once said, an error doesn't become a mistake until you refuse to correct it.

There's no reason to metaphorically crucify someone for an honest mistake, but certainly there is going to be a reaction to it and people aren't going to like it. That's to be expected. It's reasonable to expect someone to accept that and yes, it is an incentive to learn something from the experience and be more careful in the future. If I were a programmer and found that completely unacceptable, I could always choose not to work on such an important project critical to the security of so many.

As an aside: I think replying to you is much more edifying than being like the cowards who modded you down to -1 without once putting forth their own viewpoint which they clearly think is superior. There's too much of that going on at this site. There is no "-1 Disagree" mod for a reason.

Re:I would think

[Anonymous Coward]

If you think than phrase means OSS is bug free, you have misunderstood it.

I think if more people correctly understood what "all bugs are shallow" really meant, it would decrease people's enthusiasm for Open Source. You are correct, the aphorism is much more modest than most people believe.

Re:I would think

[machine321]

Does OpenVMS still require the byzantine workarounds that were in OpenSSL, or can it compile modern software without substantial changes?

I think part of the problem is that the OpenSSL developers are publishing code paths that they never test; this was tedu@'s original frustration when trying to disable the OpenSSL internal memory management; there was a knob to turn that nobody had tested, and the code was too hard to read to make the bug obvious.

If there's a demand for OpenVMS SSL libraries, they obviously can continue to use OpenSSL, or someone can re-port this new SSL library.

Re:I would think

[machine321]

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

"Many eyes" rarely helps; you need to get the right eyes to look at a bug. If you follow vulnerabilities, you'll notice a handful of people find most of the bugs. The main advantage of open source is that the code is available for those eyes to view.

Re:I would think

[cold fjord]

Both hats off and donations to OpenBSD are in order.

Re:I would think

[Chaos Incarnate]

The goal here isn't to review individual commits; it's to get the code to a more maintainable place so that it can be audited as a whole for the vulnerabilities that have cropped up over the years.

Re:I would think

[0xdeaddead]

hearbeats just exposed their faulty malloc replacement. so who knows what else is lurking, and all the more reason to remove cruft like VMS. HP's EOL'd it, just let it die already.

Re:I would think

[Halo1]

Does OpenVMS still require the byzantine workarounds that were in OpenSSL, or can it compile modern software without substantial changes?

The message I linked to at least adds several lines to a file called "symhacks.h" to deal with limits regarding the length of symbol names (which is probably required due to a limitation of the used object file format on that platform, and hence not easily resolvable by changing the compiler or linker).

I think part of the problem is that the OpenSSL developers are publishing code paths that they never test;

Conversely, I think part of the current cleanup is that it's not just a cleanup of bad/dangerous code, but also throwing away functionality/support that the people performing said cleanup personally don't consider to be relevant. It's their full right to do so, of course, but it's a rather bad example if the intention is to show how badly OpenSSL is supposedly maintained.

If there's a demand for OpenVMS SSL libraries

I'm not sure why you put this conditionally, since there obviously is such a demand.

Re:I would think

[SuperTechnoNerd]

From a brief glance it seems the freelist was barely useful, since if the chunksize you wanted was not the chunksize of elements in the list, you had to resort to a normal malloc anyway. Seems the size of the first entry in the freelist lifo dictated the size of all the chunks in the list. Seems a lot of effort for little return.

Re:I would think

[amiga3D]

This is one of the more insightful and reasoned comments I've read on /. in a long while. Sadly I have no mod points.

Re:I would think

[arth1]

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.

At least a couple of reasons:
- First of all, OpenSSL was designed with much slower hardware in mind. MUCH slower. And much of is in still in use - embedded devices that last for 15+ years, for example.
- Then there's the problem that while you can dedicate your PC to SSL, the other end seldom can. A single server may serve hundreds or thousands of requests, and doesn't have enough CPUs to dedicate one to each client. Being frugal with resources is very important when it comes to client/server communications, both on the network side and the server side.

Certain critical functionality should be written highly optimized in low level languages, with out-of-the-box solutions for cutting Gordian knots and reduce delays.
A problem is when you get code contributes who think high level and write low level, like in this case. Keeping unerring mental track of what's data, pointers and pointers to pointers and pointers to array elements isn't just a good idea in C - it's a must.
But doing it correctly does pay off. The often repeated mantra that high level language compilers do a better job than humans isn't true, and doesn't become true through repetition. The compilers can do no better than the person programming them, and for a finite size compiler, the optimizations are generic, not specific. And a good low level programmer can take knowledge into effect that the compiler doesn't have.
The downside is a higher risk - the programmer has to be truly good, and understand the complete impact of any code change. And the APIs have to be written in stone, so an optimization doesn't break something when an API changes.

Re:I would think

[SuperTechnoNerd]

I saw that too. It does seem sloppy, but of course it was not actuall "free" but sitting in the lifo.
It was an un-dead chunk of memory :)

Re:I would think

[Anonymous Coward]

Both hats off and donations to OpenBSD are in order.

absolutely! http://www.openbsdfoundation.org/donations.html

Re:I would think

[Bite The Pillow]

Also, this does not seem like a rush. Competent people who can write good code quickly, committing changes as they are found, can result in huge numbers of commits.

They just happen to have a reason to make all of the changes people have been suggesting for years to make it clean.

"rush" was a false premise. Mentioned twice, probably for maximum troll, because rush code is bad. Experienced coders writing in familiar, known patterns, is not rushed.

Re:I would think

[arth1]

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.

Not necessarily - if they used their own allocation routines (which it appears they did), it could have an API allowing use after free until a new allocation occurred. If so, the bug would be replacing the memory allocation routines without also rewriting the parts that depended on the old functionality.
And before someone going on a rant saying that that's a brain dead thing to do, it's something that pretty much every compiler does when using the stack. The stack pointer isn't going to change until you change it. So if using a private stack for memory allocation, this is perfectly fine. It's a different API to what's common, but different doesn't mean wrong. It just means that those who use it have to understand it and not make erroneous assumptions.

Re:I would think

[Bengie]

Will probably have to change to another name though.

LibSSL

Re:I would think

[Halo1]

but it's a rather bad example if the intention is to show how badly OpenSSL is supposedly maintained.

The intention isn't to show how badly OpenSSL is maintained. The intention is to create a good version of OpenSSL. One easy way to do that is to reduce OpenSSL to a reasonable, clean core without all the complexity of cruft and hacks that are clearly no longer understood or maintained by even the OpenSSL team themselves.

You may want to read my entire message again. It was about comments like yours, not about the cleanup initiative itself.

Re:I would think

[gbjbaanb]

no, nononono. "could have" is never what you want to be reading when you're talking about whether code is correct or not.

Now, sure a compiler can do it - as it knows exactly what its doing, optimisations make sense at that level as it can perform that optimisation in a safe way. But if you're relying on your own 'optimisation' against what the compiler may do as well, then you're generally going to be screwed. You must always stick with the API spec, and if the API says "never use something after its been freed" then you never use it after its been freed.

Even if they do have a free is just "unreserve" memory, then its pretty bad practice to a) call it free, b) use it in a way that makes it look like it should be freed like every other allocator out there. Don't surprise people is essential.

Re:I would think

[XO]

... and in a system with a good code review system, this probably would have never happened to begin with, because once you require more than a couple of people look at it, weird mistakes like that usually get caught. at least, if they are thinking about it. Pretty much all the major code errors i've seen in peer review systems get through when people just start blindly accepting code, or only comb it for style related issues. Serious flaws like what caused Heartbleed are pretty difficult to get through multiple people that are thinking.

Re:I would think

[XO]

The point should be, that open source CAN be superior in these respects. It's probably pretty likely that no one but the original code author of this bug actually considered what the code was doing, and just said "Hey, looks good, accept pull request." and then no one else looked at it.

Re:I would think

[DahGhostfacedFiddlah]

Does anyone else think that hundreds of commits in a week is a BAD thing?

I'm glad I'm not the only one with this reaction. Maybe I'm just a bad coder who's only worked with bad coders, but I've never seen a hundred commits that didn't introduce their fair share of bugs - let alone a hundred commits in a single week.

Re:I would think

[vux984]

but I've never seen a hundred commits that didn't introduce their fair share of bugs - let alone a hundred commits in a single week.

Take a look at the commits.

Majority of them are things like

sometype
*name

to

sometype *
name

and fixing indentation, formatting comments, etc

The ones that actually -change- anything significant are FAR fewer, and most of those are simple straight elimination of special platform specific paths, for platforms they don't wish to support in this fork.

Very few actual bugs are being eliminated. No new features. The number of "real code" commits is very nominal.

Re:I would think

[WaffleMonster]

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.

VMS is not dead. A number of open source projects continue to support it because users still need it. Preprocessor macro's containing code specific to VMS don't hurt anyone but VMS users.

Having spent some time looking thru diffs it is not obvious to me much of anything was actually fixed. Mostly doing by hand what code re-formatting tools can do automatically and with much less chance of error.

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.

From what I have seen from changes there is no evidence this team is acting responsibly.

Re:I would think

[sjames]

This is being done in a fork of the code. Step one is to chainsaw out the pile of deadwood and obvious errors as well as a particularly nasty 'feature' that made heartbleed more than a curiosity (that would be the replacement malloc/free).

Looking at the commits, in some cases they're zeroing pointers after free to make it fail hard on use after free bugs rather than usually getting away with it.

Re:I would think

[sjames]

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

Sometimes the cruft is so deep you can't read the code properly anymore. It has to go so you can see where things stand. Sometimes it's actually papering over bugs. You have to take the paper down to see papered over bugs clearly. One reason for a lot of commits is when you keep the individual changes small and documented. It's better in cases like this to have 100 commits of small changes with individual commit messages rather than having one big one at the end of the week marked "A whole heap of stuff".

Re:I would think

[sjames]

That's a two fer. Had they used the standard malloc and turned on poisoning they would have turned a subtle bug that might occasionally leak data into a hard crash that could be quickly found and addressed.

Re:I would think

[DahGhostfacedFiddlah]

"Take a look at the commits"?! I barely read the summary, and like it that way!

..but yeah - thanks for providing a reality check on my knee-jerk reaction. From your description, it doesn't sound like the crazy-commit-fest I'd envisioned from the headline.

Re:I would think

[arth1]

Also..OpenVMS has not been updated in almost 4 years. If you have native servers on these machines exposed to the internet, you get what you deserver regardless of the version of openssl you're running. Tell you what - you maintain the OpenVMS patches and I'm sure no one will stop you. Otherwise, stop complaining about it.

They don't need to be on the internet - they may be running back-end or internal systems. But if front-end systems or internal PC or midrange systems communicate with them using openssl, the versions have to be compatible. You can't just upgrade one end of the connection, at least not without extra testing.
Or, it might be a system that has to be accessible and visible to just a small part of the internal userbase, and you protect it from internal hacking.
So legacy systems sometimes need software upgrades too.

Re:I would think

[am 2k]

The often repeated mantra that high level language compilers do a better job than humans isn't true, and doesn't become true through repetition. The compilers can do no better than the person programming them, and for a finite size compiler, the optimizations are generic, not specific. And a good low level programmer can take knowledge into effect that the compiler doesn't have.

While I agree, there are also specific cases where a human cannot reasonably do an optimisation a compiler has no troubles with. For example, a CPU can parallelize subsequent operations that are distinct, like talking to different units (floating point math, integer math, memory access) and not using the same registers. A human usually thinks in sequences, which require using the result of an operation as the input for the next operation. Everything else would be unreadable source.

Finding distinct operations and re-ordering commands is easy in compilers, and the optimized result has no requirement of being readable.

C tries to find a middle ground there, where the user still has a lot of possibilities to control the outcome, but the compiler knows enough about the code to do some optimizations. The question is where the correct balance lies.

Re:I would think

[am 2k]

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?

I guess you're not a programmer? When programming, you develop mind models of the code. This means that you can see behind the structures and write complicated stuff very quickly. After a while of not working on the code, you forget that model, and small changes are very dangerous, since they might result in side effects in other parts of the code you didn't consider.

That means that when you're constantly working on the same codebase and add features quickly, you get better code and less bugs. Note that this only stands true without a deadline looming ahead (which I don't think the OpenBSD devs have), since then you tend to make dangerous shortcuts and litter the code with "FIXME"s you tend to forget about.

That's also how hackathons work. I've been able to create full products in a weekend that otherwise would have taken months.

Re:I would think

[Bengie]

Mind models can take days to rebuild. I hate switching projects.

Re:I would think

[beelsebob]

Actually, you (oddly) do very much care about speed in OpenSSL. One of the most successful types of attack against security algorithms involves measuring how long it takes to do things, and inferring the complexity of the calculation from that. Taking any significant amount of time makes measurement easier, and errors smaller, and hence this type of attack easier.

Re:I would think

[DutchUncle]

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.
Correct reasoning: when the condition of "many eyes" was met, the premise is shown to be true.

Faulty common inference from the true premise: When source is open, many eyes will be looking at it.

It seems the reverse occurs: People start to trust the *small* group actually doing work on any particular project, and since it is nobody's assigned responsibility to review it, nobody does. Yes, when a fire occurs there are many volunteer firemen; but that's a little late.

Re:I would think

[Zero__Kelvin]

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

Well that certainly explains why you are so upset about it!

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

No, but your post is a prime example of some idiot trying to win an argument he can't possibly win by trying to reframe the discussion with lies. Nobody ever made the claim that FOSS is bug free, and you are a complete moron for trying to act is though they did.

I used to think that Michael Jordan is much better than me at basketball, but then he missed a basket, which according to you is proof I'm better than him!

Re:I would think

[Zero__Kelvin]

"I'm simply pointing out, that a talking bullet of open source, is no longer valid. "

You are simply trolling. Period. Nobody is such a moron that they actually beleive that; not even you.

Re:I would think

[Anonymous Coward]

Reminds me of a tale I was told of a trader who screwed up and cost his bank £50M in half an hour. He went to the big boss to resign, but the boss refused, saying "I've just paid £50M for you to learn an important lesson. Why the hell would I let you go now?"

Re:I would think

[lucm]

The downside is a higher risk - the programmer has to be truly good, and understand the complete impact of any code change.

This is a very important point. Hundreds of commits is not an indicator of quality, it's an indicator of risk. Unfortunately nowadays developers are obsessed with unit tests; regression tests are not sexy enough.

Odds are that the next major bug in OpenSSL won't be a problem with variables or memory allocation; it will be a loophole found in the interaction between methods updated by different teams.

Re:I would think

[Zero__Kelvin]

"No, terrible analogy."

You seem to think that because you are too stupid to understand it, that it is incorrect.

"Michael Jordan is a paid professional. You are not, but because you are free, thousands cheer for you, after all, you never miss a basket (because thousands cheer for you).

Blam, you miss a basket. Only fucking idiots would still be cheering for you."

You are too stupid to figure out that the people who write OSS are more often than not professionals. The fact that you think ametuers could write something as complex and ubiquitous as OpenSSL is prima facia evidence of your idiocy. Now off you go little cognitively challenged troll ...

Re:I would think

[Zero__Kelvin]

"Absolutely - trolling to me is getting idiots to prove themselves incompetent. "

Holy shit! You done trolled yourself!

Re:I would think

[lgw]

The people fixing it aren't the people who made the mistakes, is the thing. This is the clean up crew, and entirely the wrong people to mock. And if you've any doubt at all about whether these guys are ocking the people who did make the mistake, well, this is Theo de Raanter we're talking about here, yes, mocking happened sure as the Sun rose.

Re:I would think

[lgw]

Except that's BS. There are probably a million "front end" webservers in use by cloud-scale products today, between Google, Amazon, Microsoft, and Facebook. None of them are at 100% CPU. Web servers just don't run that kind of load. There's simply no system performance cost here. Bit of power and cooling maybe, but trivial in the scheme of things.

Re:I would think

[Anonymuous Coward]

[snipped long litany of cliches and platitudes]

If I were a programmer

That's the problem: you're not.

and found that completely unacceptable, I could always choose not to work on such an important project critical to the security of so many.

That the old tired meme used to keep honest competent people out of critical jobs; but unlike generals and politicians, programmers able to work on OpenSSL don't grow up in trees, so you will have to make do with (almost) the same people and stuff your "incentives" and "reactions" up your ass.

Re:I would think

[JDG1980]

That code is not dead, there are actually still people using OpenSSL on OpenVMS and actively providing patches for it

Then maybe they should be maintaining their own version of OpenSSL, rather than inflicting their unnecessary complexity on the other 99.9% of users and dragging down everyone else's code quality along with them.

Re:I would think

[JDG1980]

Preprocessor macro's containing code specific to VMS don't hurt anyone but VMS users.

Yes, it does. Using these macros everywhere makes the code more opaque, thus less legible, and therefore less secure. "Many eyes" can't make all bugs shallow if those eyes don't understand what the hell they are looking at.

Re:I would think

[Spiked_Three]

would you call that whining? or twitching? I'm having a hard time classifying it..

Re:I would think

[EvanED]

And before someone going on a rant saying that that's a brain dead thing to do, it's something that pretty much every compiler does when using the stack.

Um, no.

The compiler doesn't really generate code that expects local variables to persist across function returns, which would be the equivalent to what we're talking about here. The one possible exception I can think of is that you could sort of argue that ABIs where there's a red zone beneath the stack pointer fit your description, but I would dispute even that.

The way the allocator is "supposed to" behave -- like a LIFO -- is like the compiler's use of the stack. The use-after-free is not.

Re:I would think

[manu0601]

[most of the commits are cosmetics]

In other words, they are making impossible to easily backport their real fixes to the OpenSSL project

Re:I would think

[Pseudonym Authority]

I'm sure Google, or anyone else who will incur a million dollar bill power bill increase for every change of O(2n) to O(2.01n), is perfectly capable of hacking optimizations in themselves.

Re:I would think

[Barsteward]

Don't believe it. An honest banker? no such beast.

Re:I would think

[Barsteward]

"I have yet to see one valid counter point" - it was all said on a previous topic about openssl, go and read the comments there for an answer

Re:I would think

[savuporo]

>> And much of is in still in use - embedded devices that last for 15+ years, for example.

Nobody in their right mind uses OpenSSL in embedded projects. There are much better suited alternatives out there.

The line between "embedded" or non-embedded systems is somewhere where you have an MMU to use or not.

Re:I would think

[TheLink]

How about call it "SpreadOpenSSL" or similar. Truth in advertising and all that.

Re:I would think

[TheLink]

Taking any significant amount of time makes measurement easier, and errors smaller, and hence this type of attack easier.

Unless you only respond after X + random Y milliseconds, no matter how long it actually takes to do the calculation (where X milliseconds is longer than the max time it takes to do the calculation).

Takes more time, but makes timing attacks a lot harder.

Re:I would think

[vux984]

Yes, this is true. But they are also making it a lot more possible to actually find the things that need fixing.

Re:I would think

[manu0601]

Well, perhaps finding things to fix should be the job of static code analyser.

I saw Coverity made progress to detect Heartbleed-like bugs in OpenSSL.

Re:I would think

[Simon Brooke]

The often repeated mantra that high level language compilers do a better job than humans isn't true, and doesn't become true through repetition. The compilers can do no better than the person programming them, and for a finite size compiler, the optimizations are generic, not specific. And a good low level programmer can take knowledge into effect that the compiler doesn't have.

Two things. Programmers are expensive, silicon is cheap. And really good low-level programmers (which I am not and don't claim to be) are (and deserve to be) very expensive indeed.

When you're writing a bit of code which is going to run on hundreds of thousands of processors all over the world (as OpenSSL is), the cost/benefit does move in low-level programmings favour. If you save just a few cycles on each of billions of operations on millions of processors, it's worth throwing resource at that optimisation. But OpenSSL (like the Linux kernel) is a special case. Most perfectly ordinary good programmers will write more cost-effective code using languages which don't require them (for example) to keep track of memory assignment.

Also, most human beings can't hold an effective map in their minds of the operating states of a moderately complex program. And people make mistakes - even the best of us.Software, by contrast, is very good at detail, repetitious, complex tasks like keeping track of what bit of memory has been assigned for what purpose, and noticing when nothing remaining in the system holds a pointer to that data. There are whole classes of programming error which good compilers will simply never make.

I was doing a post-accident audit on safety-critical (closed source) code a few years ago. The reason for the failure was that someone had used strcat to concatenate strings for an error message, where the strings being concatenated were stored in the data segment (yes, think about it for a moment). It cost millions of pounds worth of damage, and it was very lucky no-one died. If the software concerned had been written in (for example) Java, the accident wouldn't have happened. Yet the software had been written by a very senior C++ programmer, and had gone through four separate code reviews before being accepted into service - and all four had missed it.

Re:I would think

[WaffleMonster]

Yes, it does. Using these macros everywhere makes the code more opaque, thus less legible, and therefore less secure.

Is this 2014 or 1994? My IDE automatically colors out dead sections where preprocessor macros don't apply to me. Honestly if you are unable to understand or mentally deal with a few preprocessor macro's I don't want you anywhere near openSSL.

They are hardly "everywhere" mostly in the headers and abstraction layers which provide a common target and normalized behavior for supported platforms.

"Many eyes" can't make all bugs shallow if those eyes don't understand what the hell they are looking at.

If eyes stumble on a few preprocessor definitions the chance of them discovering anything useful in this project is zero. I'm all for making shit easier to understand but this specific kind of "premature optimization" accomplishes nothing.

Re:I would think

[marcello_dl]

This has nothing to do with the proverbial barn doors.

I closed the barn door as soon as the patch was available, and for debian I had the patch available even before I got the news about heartbleed. If other people sell systems which are not as easily patchable as debian, they are the other problem.
The first problem, that openssl was not all that great, was known. Read this story.

Re:I would think

[goose-incarnated]

Yes, it does. Using these macros everywhere makes the code more opaque, thus less legible, and therefore less secure.

Is this 2014 or 1994? My IDE automatically colors out dead sections where preprocessor macros don't apply to me. Honestly if you are unable to understand or mentally deal with a few preprocessor macro's I don't want you anywhere near openSSL.

They are hardly "everywhere" mostly in the headers and abstraction layers which provide a common target and normalized behavior for supported platforms.

"Many eyes" can't make all bugs shallow if those eyes don't understand what the hell they are looking at.

If eyes stumble on a few preprocessor definitions the chance of them discovering anything useful in this project is zero. I'm all for making shit easier to understand but this specific kind of "premature optimization" accomplishes nothing.

#ifdef VMS
#define SOMEFUNC(x,y,z) SomeVmsFunc (z,y,x)
#else
#define SOMEFUNC(x,y,z) TotallyOtherFunc (x,y,z)
#endif

You don't see how that fucks up the legibility of code? You encounter SOMEFUNC(1,2,3); and you have no idea what it does and your damn IDE can't colour-code that away either.

Re:I would think

[WaffleMonster]

#ifdef VMS
  #define SOMEFUNC(x,y,z) SomeVmsFunc (z,y,x)
  #else
  #define SOMEFUNC(x,y,z) TotallyOtherFunc (x,y,z)
  #endif

You don't see how that fucks up the legibility of code?

No, when the function is used I know what it is doing because I know what SOMEFUNC is supposed to do. If SOMEFUNC does something other than what it is supposed to do then I can trace it and go find out why.

You encounter SOMEFUNC(1,2,3); and you have no idea what it does and your damn IDE can't colour-code that away either.

If you don't know what a function does you can check the documentation, ask someone who knows or go read the source code. This is applicable to every function. If I'm in my IDE I can step into the function and see what it does for myself. The comment coloring applies when a block is not applicable to my environment. For example the VMS definition. I does not hide the fact that it is a preprocessor def.

What do you think autotools is? Every open source project I have ever seen is littered with this compatibility crap. Entire header files dedicated to providing replacements and making up for lack of support for god knows what. All manner of functions individually probed by a gnarly meta program at compile time. Do you not realize just about every open source package included with any mainstream distro does this shit?

Re:I would think

[WaffleMonster]

If your IDE is automatically coloring them out, you might as well actually throw them out. They do not help.

The code does not help me but it does help other people. Throwing it out just because I don't care is selfish and counterproductive.

They only take up space. They won't be tested. They will bit rot as the surrounding code changes.

See above.

It's a lot of mental work to remember all the subtle differences, and why bother if you can just use the standard functions that are everywhere and have been there for 15 years?

Back in the real world we often have to deal with decades old crap including ancient platforms with broken or missing implementations of basic functionality. Closing your eyes, pretending otherwise or not understanding this reality out of ignorance solves nothing.

Okay, I get it. You're a genius superhuman elite hero. You are better than the OpenSSL developers; you wouldn't make a mistake they made with one of these crazy functions that looks standard but isn't.

I'm a superhuman idiot zero who has been contributing to open source projects for decades. What crazy functions specifically are you referencing?

You are better than the OpenBSD developers who need to restyle the code and remove wrappers and layers to make it less confusing to work with.

It does not take a rocket scientist to see the hubris billowing out of unprofessional commit comments. Been around enough to see the difference between making a difference and scratching obsessive compulsive itch. See also hasty deletes subsequently being reversed.. "oops".

Why don't you make your own fork and show the world how much better you are? You could probably do it. The most secure SSL/crypto library. Or would you rather run upstream OpenSSL

I'm happy with OpenSSL project especially now they recently added crypto features I have been waiting the better part of a decade to become field deployable.

If I find any problem in the code I have no reason to believe a vigorous patch would not be happily accepted by the OpenSSL team. OpenSSL is also heavily used by tiny companies like Google. They have made a great number of important contributions.

Or would you rather run upstream OpenSSL since you seem to have disregarded all the bugfixes the OpenBSD developers did, and claim they have no security value?

I made no such claim. I have never said OpenBSD devs have done nothing of value. I simply question the aggregate value of the changes commensurate with the hype used to describe them and think most of the commits I have checked with my own eyes are counterproductive or worthless. Most of them by volume are nothing more than adjustments to spacing between variable names and equal signs.

Of course you know better. You probably audited all the code already...

I will say the absence of anyone publically announcing discovery of any new bugs of substance post heartbleed is telling in and of itself. While I assume OpenSSL is full of undiscovered (or at least undisclosed) security critical bugs if all the code "sucks" as bad as heartbleed did I would expect to see quite a different outcome.

Compared with other security critical system that is as widely deployed I don't know that OpenSSL 's vulnerability track record is out of line from what can be expected.

People talk about OpenBSD developers as if they are gods yet a few seconds of googling shows plenty of dangerous CVE's for OpenSSH flaws disclosed during OpenBSD ownership of the project.

I think more eyes are good. I think anyone who wants to contribute bug fixes or make the project better is good. My objection is in unnecessary removal of functionality others still need and the characterization of OpenBSD commits as substantive when they are mostly shallow format

Re:I would think

[vux984]

Well, perhaps finding things to fix should be the job of static code analyser.

Because static code analysers can catch all bugs?

Re:I would think

[Redmancometh]

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

I've never heard this, but I'm stealing it.

Re:I would think

[causality]

Well written and very insightful except for one thing...the guy really was trolling.

Ever heard of the principle of non-resistance? If he really was trolling then my post will affect him more than it could affect anyone else.

I don't really think he was. I think he made an emotional outburst reflecting his view of an unpleasant (but improving) situation. That can seem like trolling especially when it turns into a big story (among techies anyway) like this did. But I don't claim to know his heart and I could be wrong, in which case the above applies.

Re:I would think

[causality]

That's the problem: you're not.

If you are conducting the surveillance of me necessary to make that determination, then your surveillance is faulty. I merely gave an example scenario and I don't share this puerile urge to make everything into a personal matter. So I wrote in such a way that I made no claims about my own programming skill or lack thereof, in order to provide a hypothetical. What I wrote is equally true whether I've never seen a compiler before or whether I am an advanced expert.

The hostility you have makes you appear stupid because it prevents you from thinking of such things. After all, such things might make me seem reasonable and level-headed. That would be like giving aid and comfort to The Enemy, right?

That the old tired meme used to keep honest competent people out of critical jobs; but unlike generals and politicians, programmers able to work on OpenSSL don't grow up in trees, so you will have to make do with (almost) the same people and stuff your "incentives" and "reactions" up your ass.

At no point did I say that anyone should or shouldn't work on this project. Re-read it yourself if you doubt I know what I wrote. To paraphrase: what I said is that it's an unusually important project and therefore the work involves higher stakes. No one is really going to care very much if you screw up a free single-player solitaire game. If you screw up SSL, that can impact many other people in negative ways. By saying that I am hardly keeping competent people from their jobs, though it's flattering that you would ascribe to me such power.

This isn't difficult to acknowledge; at least, it certainly shouldn't be. Is there something about saying it that makes you so angry? Were you built up by praise you didn't really earn and are coming to realize how fragile a foundation that really is, or what (by means of my "platitudes")? Beware of hating someone for no good reason, someone who means well by you and wants good things for you. It's one of the more toxic ways you can pollute yourself.

Re:I would think

[smash]

If I find any problem in the code I have no reason to believe a vigorous patch would not be happily accepted by the OpenSSL team

You're living in fantasy land. There was a 1-2 line patch that would have fixed heartbleed sitting in the bug tracker waiting to be actioned for over 18 months.

code review time!

[Anonymous Coward]

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

Re:code review time!

[Anonymous Coward]

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

Re:code review time!

[Anonymous Coward]

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!

[St.Creed]

The NSA, obviously.

Next question please.

Re:code review time!

[Anonymous Coward]

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.

Wow when Family Guy picked that one up it really cemented it in the minds of meme-repeating sheople like you.

"Sure I could try to make my own point with my own reasoning. I could do that. I could try anyway. But look! There's a bunch of pre-fabricated pre-packaged thought blobs. Wow! Now the tiny effort of saying what's on my mind is reduced to no effort at all. I'll just present one of these manufactured thoughts and pretend like I did something witty. That'll show 'em!"

Re:code review time!

[Ja'Achan]

99 little bugs on the wall, 99 little bugs

Pin one down, patch it around, 128 little bugs on the wall

Re:code review time!

[budgenator]

Must be enough to make your head explode working at the NSA, half your people want to be able to break into any computer, the other half wanting o make it impossible to break into any computers.

Re:code review time!

[Bengie]

They've removed over 50,000 lines of code as of several days ago. I'm sure there are fewer bugs.

Re:code review time!

[whogivesafuckingfuck]

> Food for thought: Is it even remotely possible that the very act of removing those 50K lines will, in and of itself, unknowingly and unintentionally expose additional bugs?

The largest removals were strictly dead code. I.e. code that has not been and never will be compiled on OpenBSD. Removing that cannot introduce bugs.

Other removals include very obviously broken re-implementations of library functions like calloc, to be replaced with calls to the real function.

The crappy pseudo rng was removed, and replaced with calls to arc4random which is hard to misuse. Along with this change went some rather questionable tricks ("hey, let's feed rsa keys and our private exponent to the rng if it runs out of entropy"). Some APIs became no-ops, so they can no longer be abused.

There are other changes which are more refactoring than removal. These did (and do) include the occassional mistake, but they get spotted pretty quick.

Someone up the thread asked who is reviewing these changes? Well, I can assure you that many people are. But it can not hurt to have an extra pair of eyeballs so anyone reading this -- please join the effort and watch the diffs. If you see a mistake, you can email the developer or tech@.

Good Job Guys

[flyneye]

Lotta work,good reason, good job guys.

WTF IS KNA TLA?

[Anonymous Coward]

Thanks editors.

KNF - Kernel Normal Form

I assume this is an R&D exercise?

[Anonymous Coward]

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?

[Anonymous Coward]

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

Re:I assume this is an R&D exercise?

[loufoque]

I usually do 10 to 20 commits per day when I'm fully dedicated to a project.
5 days a week, and they're 5 people, that's 5*5*(10 or 20) = 250 or 500.

Merged back or fork?

[dutchwhizzman]

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?

[badger.foo]

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?

[toonces33]

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?

[petermgreen]

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?

[smash]

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?

[serviscope_minor]

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?

[jones_supa]

It's good that they are ripping out some of the portability. For most people, x86-64 and Linux/BSD/Windows support should be enough in modern days. Many OSS projects are overly portable and they unnecessarily brag how they support all the crusty HP-UX and SGI workstations with ages-old libraries and special legacy implementations. By cutting that support out, problems are avoided and the code is made more clean.

Re:Merged back or fork?

[cold fjord]

There are old systems out there so perverse, they poison almost every part of your code

There are people out there deeply attached to their 6, 9, or 12 bit bytes and 36 or 60 bit words, you insensitive clod! ;)

Re:Merged back or fork?

[laffer1]

Ironically, OpenBSD is one of the projects that supports a lot of crusty old architectures using the logic that it helps them find bugs.

This logic is often used by Linux people not to support *BSD. I don't agree with the crusty old platform argument.

Re:Merged back or fork?

[laffer1]

I would argue that things don't just compile on FreeBSD. In fact, if you change the uname to something else, many things don't work. There are a lot of FreeBSD specific hacks in source code from many popular projects.

I would know since I have to deal with it all the time in my BSD project.

Re:Merged back or fork?

[serviscope_minor]

I would argue that things don't just compile on FreeBSD. In fact, if you change the uname to something else, many things don't work. There are a lot of FreeBSD specific hacks in source code from many popular projects.

To some extent yes. However, much of encryption is heavily algorithmic code, and that should be portable. When I mean old, perverse systems, I'm referring to really old perverse systems. Like ones so ad they couldn't even rely on something as deeply embedded in the C standard as malloc() to work reliably.

Once you have systems like that, things get screwey really fast.

I think there was another one for VMS where on a 64 bit build, the ARGV thing would sometimes come in as a 32 bit only pointer.

By the time you're portint from modern OpenBSD to modern Linux, things will probably be somewhat easier. And from your point of view, it's probaly better than that because OpenBSD is moresimilar to FreeBSD than to Linux.

Re:Merged back or fork?

[jones_supa]

Striving for the ultimate portability forces you to make all sorts of fancy wrappers around basic functions. Before OpenBSD now started to fix OpenSSL, there was even a function called get_current_time() which was a wrapper around the classic gettimeofday().

Re:Merged back or fork?

[toonces33]

If you want to remove portability to only truly dead OS versions, that's one thing. But I saw a patch that removed portability to Windows. And most certainly something sort of like that would need to be added back again in some form or another. And by doing all of this, what have you accomplished other than potentially introducing new bugs?

Re:Merged back or fork?

[toonces33]

Except for Windows. I have seen patches that remove windows portability, so the windows port and portability code will need to all be done over again.

Re:Merged back or fork?

[laffer1]

I never said one should port to all platforms and architectures. There's a balance and that is mostly to do with the resources a software project or individual has. For example, I dropped Sparc64 support in MidnightBSD because I don't have the time to maintain it. It also took 2 weeks to build packages on my two sparc systems.

Re:Merged back or fork?

[serviscope_minor]

Except for Windows. I have seen patches that remove windows portability, so the windows port and portability code will need to all be done over again.

Yep.

But it's easier to insert new portability stuff into clean code than to fix the bugs in the old portability layer. Besides, there are plenty of good, debugged compatibility layers for porting unix code to windows should anyone want their server software running on Windows.

Re:Merged back or fork?

[jones_supa]

A chocolate bar wrapper.

Re:Merged back or fork?

[jones_supa]

You are absolutely correct.

Re:Merged back or fork?

[fuzzywig]

The commit to remove bigendian x86 is particularly hilarious:

Remove support for big-endian i386 and amd64.
Before someone suggests the OpenSSL people are junkies, here is what they mention about this:

/* Most will argue that x86_64 is always little-endian. Well,
* yes, but then we have stratus.com who has modified gcc to
* "emulate" big-endian on x86. Is there evidence that they
* [or somebody else] won't do same for x86_64? Naturally no.
* And this line is waiting ready for that brave soul:-) */

So, yes, they are on drugs. But they are not alone, the stratus.com people are, too.

Re:Merged back or fork?

[smash]

If you looked at some of the commits and comments regarding the Windows support, you'd want to kill it with fire too. Not because it's ported to Windows, because of some of the brain damage that was in that port.

it's a good effort

[tero]

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

[aliquis]

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

[sqlrob]

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

Re:it's a good effort

[budgenator]

ADA!

Re:it's a good effort

[bill_mcgonigle]

yep. This may be a case of "medicine that tastes awful".

Re:it's a good effort

[Barsteward]

fucking ada http://www.youtube.com/watch?v...

Re:it's a good effort

[Tom]

however there is considerable risk that the rush will cause new bugs

That's a risk you always have and thus not a valid counter-argument. And if anyone has experience in doing this kind of cleanup work in a way that doesn't, then it's the OpenBSD team, because they've done this before.

Too specific?

[Anonymous Coward]

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

Re:Too specific?

[jones_supa]

Yes. This is why you should cut out unnecessary portability for legacy platforms (for example old HP/SPARC/SGI UNIX machines which should be in a computer history museum anyway).

Re:Too specific?

[Viol8]

Sometimes yes - but often its down to an attempt at a "framework" some idiot tried to add in lieu of writing some actually useful code (which is the usual reason for frameworks arising - those who can - code, those who can't write frameworks).

Re:Too specific?

[thebjorn]

Without looking at the code or the commits...

... you should probably not talk about things you don't know anything about..?

This isn't fixing SSL

[beezly]

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

[beezly]

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

Re:This isn't fixing SSL

[badger.foo]

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.

Re:This isn't fixing SSL

[beezly]

I did look at the commits. They're all to OpenBSD, not OpenSSL.

Are they still running it through Coverity ?

[bheading]

OpenSSL is on the list of projects scanned by Coverity.

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 ?

[Anonymous Coward]

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 ?

[ledow]

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.

Re:Are they still running it through Coverity ?

[bheading]

Ah I should have checked that. Thanks.

Re:Are they still running it through Coverity ?

[bheading]

I know that static analysis cannot catch all problems (duh) but I was curious, as this seems like a fairly classic example of accessing tainted data which in many circumstances the analyzers can spot. The blog post referenced above explains why this is.

But is it that easy?

[swb]

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?

[gbjbaanb]

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.

Re:Quatity is not quality

[drolli]

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

[aliquis]

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.

Testing and validation is what's needed

[putaro]

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

[smash]

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

Re:Quatity is not quality

[carlhaagen]

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.

I want to know...

[msauve]

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

[satch89450]

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

Re:I want to know...

[WaffleMonster]

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)

I see a number of people here making this false argument.

In most servers the private key is stored in actual allocated memory. This bug allowed carte blanche access to whatever relative process memory location you want.

Most systems hang on to freed memory for some time before eventual eviction from process heap. Fragmentation avoidance is complex, unpredictable and non-standard.

Re:Coding style fixes are "news" for nerds?

[smash]

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

The commits are funny into themselves.

[strredwolf]

A Tumblr site popped up a few days ago called OpenSSL Valhalla Rampage. 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...), stripping out now-stupid abstractions and optimizations of the unoptimizables, and more.

Re:The commits are funny into themselves.

[St.Creed]

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.

[Bill Dimm]

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.

[Megol]

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.

[arth1]

Comparing to zero is faster in most architectures and still is a valid optimization.

Indeed, and you might want to take it even one step further, and test for --i = 0.

There's also the fact that there are plenty of older archiitecture CPUs out there, being deployed even today, especially in the embedded world where product lifecycles are really long, and switching to a new architecture can mean dozen of man-years of work.
Do you want your water company and cable provider to install new meters every two years to keep up with the latest technology? Guess who would pay for that!
In critical infrastructure it becomes even more important to support old hardware. Would you feel safer in a plane running hardware/software that has shown itself to work, or one with bleeding edge computers that crashes as often as a typical desktop?

Optimization isn't bad. But you have to know what you're doing, and why. High level developers relying on magic abstractions layers need not apply. Their strengths lie elsewhere.

Re:The commits are funny into themselves.

[JDG1980]

Indeed, and you might want to take it even one step further, and test for --i = 0.

None of this will make any difference on any compiler with half a clue. Figuring out how best to translate these constructs into machine language is the compiler's job, and modern compilers (gcc, clang, and VC++) are pretty good at it. If decrementing and comparing to 0 is faster, then a modern optimizing compiler will do that automatically even if you use for(i = 0; i < 8; i++) instead of the other way around.

Re:The commits are funny into themselves.

[ByteSlicer]

Indeed, and you might want to take it even one step further, and test for --i = 0.

Which would set i to 0...

Re:The commits are funny into themselves.

[arth1]

Ir's slashdot's wonderful messaging system that eats less-than signs even when they're not part of tags.

Re:The commits are funny into themselves.

[arth1]

If decrementing and comparing to 0 is faster, then a modern optimizing compiler will do that automatically even if you use for(i = 0; i < 8; i++) instead of the other way around.

Do you have one example of a compiler that actually does that?

gcc for example, might unroll the loop, but not revert the look to use a more efficient comparison. A quick test with icc (older version, I admit) doesn't do it either.
Which compilers do you refer to that do this?

Re:The commits are funny into themselves.

[ByteSlicer]

Yup, that happens. Preview is your friend.
It's actually the HTML tag support that does this.
You can either use entities &lt; (--i <= 0) or wrap everything between <ecode> tags (no entities needed, but it quotes the wrapped text).

--i <= 0

Re:The commits are funny into themselves.

[DTentilhao]

Seems perfectly clear to me :)

-- cut --

--- src/lib/libssl/src/crypto/asn1/tasn_dec.c 2014/04/19 17:12:39 1.19
+++ src/lib/libssl/src/crypto/asn1/tasn_dec.c 2014/04/19 18:40:49 1.20
@@ -172,12 +172,6 @@ ASN1_item_ex_d2i(ASN1_VALUE **pval, const unsigned cha

.. snip ..

if (asn1_cb && !asn1_cb(ASN1_OP_D2I_PRE, pval, it, NULL))

-- paste --

Re:The commits are funny into themselves.

[Yaur]

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.

A good compiler should take care of that optimization for you (VC11 certainly does).

Re:The commits are funny into themselves.

[david_thornley]

No, not necessarily. Code that modifies the same variable twice without an intervening sequence point is undefined, and so it could legally do anything. Practically, it would be likely to result in i being decremented by one or set to zero.

Re:The commits are funny into themselves.

[Megol]

Sometimes yes. But doing it manually doesn't just give the compiler an explicit hint even for the compilers/those cases that doesn't trigger that optimization but also IMHO is part of documenting the code. It shouldn't be a problem to write/read for a C programmer, if it is, well I'd not want to touch the code produced by that person.

Re:Quatity is not quality

[Anonymous Coward]

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.

NSA

[Lehk228]

which one of the patches is the new NSA subversion?

Thank You

[Anonymous Coward]

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

Re:Thank You

[jones_supa]

For free? This January, the very OpenBSD project almost had to halt operations as they didn't have the money to pay for the power bill for the build servers. Thankfully they did get a donation package to get over it.

Re:Coding style fixes are "news" for nerds?

[K. S. Kyosuke]

Most? 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?

Worst thing possible

[Anonymous Coward]

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.

Re:Worst thing possible

[satch89450]

You've looked at the "code changes"? I did, and found many of the alleged changes to be reformatting, to make the code easier to audit. Some of the changes are to pull out portability cruft on long-dead platforms. But you go ahead and view OpenSSL as dead to you -- that's your choice. As for "untested code changes", are you sure? This appears to be part of a process, not a rush to release.

Re:Worst thing possible

[iggymanz]

You are ignoring WHO is making these changes, they prize correctness, robustness and security above all else. they know what they are doing,

Re:Worst thing possible

[Temkin]

Some day, you should learn about automated regression testing, which allows an entire regression suite of hundreds of tests to run after every commit.

Maybe then you'll have something sensible to say.

Not just that, we're discussing changes in the tip of their source repo. Not "released" code by any strech of the imagination. We're basically spectatiors, watching one of those Bob Ross "joy of painting" shows. The picture has yet to emerge. (hmmm.... accidental Gentoo pun...)

Re:Worst thing possible

[Jeremi]

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.

And you don't think those changes are going to all be reviewed, then re-reviewed, then gone over with a dozen fine-toothed combs before anyone actually uses the new code in earnest?

It sounds like the OpenBSD people aren't the ones being stupid here.

Re:Worst thing possible

[styrotech]

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.

Let me guess... someone else who thinks that the OpenBSD team and the OpenSSL team are the same people?

Hint: they're not. This is a fork of the OpenSSL libraries used in OpenBSD and not intended for anyone else. If after some time it stabilises and turns out to be a good move (I'm guessing it will), then some other people are likely going to want to maintain a portable version that can be used on other platforms - just like what happens with openssh plus the odd other project eg openntpd.

Number of commits is meaningless

[Pop69]

Quantity doesn't equal quality

Re:Number of commits is meaningless

[iggymanz]

it means something when coming from the people who made openssh

KNF can wait

[gatkinso]

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

Deal with that later.

Re:KNF can wait

[satch89450]

It's most annoying, and couter-productive, to audit code when the lack of formatting gets in the way. The first thing I do when I get a piece of messy code is run it through a beautifer first. In one case, that one action made the bug shine like the sun on a clear day. Who audits using diffs? The audit needs to cover ALL the code.

Re:KNF can wait

[Trepidity]

Different people reformatting the code with their preferred beautifier isn't a particularly useful exercise, though.

list of changes

[monkey999]

A summary of the changes is here :

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 also:

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.

Re:list of changes

[WaffleMonster]

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.

This is like making political arguments for pure capitalism or socialism. None of them alone work in practice correct answer is always somewhere in between AND context dependent.

These changes amount to rearranging deck chairs on a sinking vessel. Deleting code is redundant when a preprocessor macro has the same effect. Changing wrapper functions and flavors of system calls could be good or bad depending on specifics.

Heartbleed is what happens when the IIWDFI attitude wins.

Heartbeat was a totally new feature.

Bugs lurk under layers of cruft, simple changes become nightmares of wading through a lava flow of wrappers around hacks around bodges

In this specific case the new code itself was sloppy and failed to perform the necessary checks.

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.

Risk mitigation is important. From diffs by volume this is not what has actually been committed. I would be all for changes that for example improved protocol parsers or did more up front validation of protocol fields before they were ever passed off internally or improving a plugin architecture for TLS extensions. Search and replace sprint/snprintf might be a good idea but I would hardly call that refactoring. I don't see any refactoring having actually taken place.

See also:

http://en.wikipedia.org/wiki/C...

Hey - Thanks OpenSSL Contributors

[bokmann]

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

Open Source is still software development

[hessian]

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:Open Source is still software development

[cheesybagel]

I disagree. Most open source projects have high code quality. For one once you have your code available for everyone to see you make a greater effort to make something decent. For another most developers I know do not like having bugs on their code. I have known a couple of occasional open source projects with poor code quality which were led by artists or other non-programmers who do not know how to do better but the number of bugs is usually less than in equivalent closed source software I know of. Documentation can indeed be a problem as since the software is constantly evolving even if someone makes the effort to document it that documentation soon gets obsoleted and useless. The best examples in documentation are usually when it is tightly integrated into the code but this is usually only doable in frameworks and other technical products like that.

Re:Open Source is still software development

[cheesybagel]

A lot of those applications in github are someone's pet project but not high profile projects. Someone thought it might be useful for someone else and put it there but it doesn't mean it is. Had you ever seen the source code of software built to order i.e. 'enterprise applications' you would realize there is software of much worse quality than even what gets into github out there.

Tests, design documents, specs depend on the situation. Specs only make sense when you are aiming for interoperability. Design documents make little sense when doing spiral development since the design is not fixed. Tests make sense however and most projects I see include tests from runtime checks to static analysis and more. Of course you are not going to bother doing that for a page of python or perl script.

Quoted from Miod Vallat

[Anonymous Coward]

> Will the fork get a new name? OpenerSSL?

"WHO CARES!

This is not about a fancy name.

This is about realizing belatedly that code we thought of good quality was not even decent, and ended up becoming too complex and unmaintainable.

So now we are hurrying to remove everything in the way of exposing the concrete guts of the code, fixing the bad practices inherited from the way we were doing security 15+ years ago, and making sure we do not break basic functionality in the process.

We have a good six weeks of work ahead of thus, simply doing this.

Then will come a second time, when we can add the few features we deem desirable, and work on spotting and fixing bugs. Then we'll need to concentrate on getting a new OpenBSD release out of the door.

Only after that, and if the above work succeeds, will we be able to consider making standalone releases of this new OpenSSL flavour, and consider working on a portable version for the other Unix-like operating systems out there.

We don't need a name for this right now.
We don't need a name for this in two weeks from now.
We don't need a name for this in two months from now."

This type of attitude is why I respect the OpenBSD team.

http://undeadly.org/cgi?action=article&sid=20140418063443&pid=3

Re:Quoted from Miod Vallat

[Sesostris III]

Just curious, but why has the OpenBSD team lost respect from you? They're not the maintainers of the official OpenSSL branch. What they're creating is a fork.

Re:They don't pay attention to Coverity

[bheading]

I have used another major static analysis tool at work, one of Coverity's competitors. And more than once have had the "if you had paid attention to the static analysis reports this problem could have been solved much more quickly and cheaply" discussion. In one case several weeks were spent chasing a particularly subtle and nasty memory tramper - which was found to be showing up in the analysis results.

False positives are certainly a concern. There is a tradeoff here in terms of dealing with the time spent (re)structuring the program so that they do not occur - a matter for the project lead. The same is true of compiler warnings. Best invest the time to clean them up and configure your build so that it breaks if they occur. You'll kick yourself later if you hit a bug that was revealed by a warning which was ignored.

Re:What's with the @s?

[mccoma]

OpenBSD lists committers by e-mail and they just don't show the domain.

Re:No Good.

[satch89450]

Mr. Anonymous Coward:

What changes are you referring to? The changes I see are good re-factoring: clean up formatting, remove dead code, add missing bounds checks

Are you volunteering to do the code audit?

Massive rush? Evidence, please.

Security testing clearly hasn't been done before? Evidence, please. The counter-evidence is that the security testing tools were found not to work in this one particular case, and that problem has been patched. Security testing costs money; how much have you donated to the project?

Heartbleed exposes a problem, it doesn't invalidate the concept of Open Source. For one example that made world-wide news, there are hundreds of examples of open-source "wins" that never rose about the journalistic "noice" because it worked properly, and didn't make any waves. The mainstream says "who do we blame, who can we sue?"

And how do you manage projects, particularly open-source projects? Does early disclosure bother me? Yes, as the admin of a group of servers. Would I be comfortable if this were done behind a wall? No. We need all the eyes we can get looking at the problem. And you need to be more explicit: are the bugs that you are complaining about being exposed exploitable in some bad way? Examples, please.

SUMMARY: It's bad, but not as bad as you make it out to be.

Pay the contributors

[AmbiLobe]

Open source should not imply free programmers. OpenSSL can start at $40 per hour. Please volunteer to pay them.

How about other OSS projects?

[jones_supa]

Now do the same to all the other important components of the OSS server software stack.

Re:Quatity is not quality

[VortexCortex]

I cant talk for C, but in Java

Haha. Oh man. Java is a VM. Do you check for "dangerous constructs" like Just In Time compiling of data into machine code at Runtime and marking data executable then running it by the Java VM? Because that's how it operates. Even just having that capability makes Java less secure, don't even have to get exploit data marked code and executed, just have to get it in memory then jump to the location of the VM code that does it for me with my registers set right. Do any of your Java code checking tools run against the entire API kitchen sink of that massive attack surface you bring with every Java program called the JRE? Do they prevent users from having tens of old deprecated Java runtimes installed at 100MB a pop, since the upgrade feature just left them there and thus are still able to be targeted explicitly by malicious code? No? Didn't think so.

Don't get me wrong, I get what you're saying, Java code can be secure, but you have to run tests against the VM and API code you'll be using too. Java based checking tools produce programs that are just as vulnerable as C code, and actually demonstrably more so when you factor in their exploit area of their operating environment. Put it this way: The C tools (valgrind) already told us that the memory manager was doing weird shit -- It was expected weird shit. No dangerous construct warning would have caught heartbleed, it's a range check error coupled with the fact that they were using custom memory management. The mem-check warnings are there, but they have been explicitly ignored. It would be like the check engine light coming on, but you know the oil pressure is fine, just the sensor is bad... so no matter how bright of a big red warning light you install it can't help you anymore, it's meaningless. Actually, it's a bit worse than that, it would be like someone knew your check engine lights were on because of some kludge they added for SPEED, and so they knew they could get away with pouring gasoline in your radiator because you wouldn't notice anything wrong until it overheated and blew up -- AND you asked them about the check engine light a few times over the past two years, but they just shrugged and said, "Don't worry about it, I haven't looked under the hood lately, but here's a bit of electrical tape if the light annoys you."

I write provably secure code all the time in C, ASM (drivers mostly), even my own languages. CPUs are a finite state machines, and program functions have finite state as well. It's fully possible to write and test code for security that performs as it should for every possible input. For bigger wordsize CPUs, Instead of testing every input, one just needs to test a sufficiently large number of them to exercise all the bit ranges and edge cases. As you've noted, automation is key. If you want to write secure code you have to think like a cracker. My build scripts automatically generate missing unit test and fuzz testing stubs based on the function signatures. Input fuzzing tests are what a security researching hacker or bug exploiting cracker will use first off on any piece of code to test for potential weakness, so if you're not using these tests your code shouldn't touch crypto or security products, it's simply not been tested. Using a bit of doc-comments to add a additional semantics I can auto generate the tests for ranges, and I don't commit code to the shared repos that doesn't have 100% test coverage in my profiler. If OpenSSL was using even just a basic code coverage tool to ensure each branch of #ifdef was compilable they'd have caught this heartbleed bug. I recompiled OpenSSL without the heartbeat option as soon as my news crawler AI caught wind of it.

Code review, chode review. These dumbasses aren't using basic ESSENTIAL testing methodology you'd use for ANY product even mildly secure: Code Coverage + memory checking is the bare minimum for anything that has to do with "credentials". They apparently also have no fuck

Lessons of the past

[gmuslera]

A previous "fix" of OpenSSL left it more insecure than it was. Just be sure to understand what you are modifying, and why even an "obvious" error was appropiate there. I suppose that also xkcd is relevant here too.

Re:Quatity is not quality

[Bengie]

OpenSSL was the epitome of horrible code. You can't make it any worse. Doing so would cause an underflow and you would have perfect code, which we know is impossible.

Re:Quatity is not quality

[drolli]

Funny. I never suggested that i would use Java for this purpose, i just pointed out that i assume that the same level of coding tools exists for C (as you stated yourself).

Regarding the VM JIT vs. statically compiled Code + and big amount of interpreters: Yes, for high-security code i definitly prefer stattically compiled code. OTOH i point out that *most* of the JVM vulnerabilities were actually not in the low layer compilation but in the somehow weird assumption that security can be managed inside the same adress space by high-level language features (which implicitely assumes that libraries of arbitrry complexity with JNI code inside are all written perfect).

Re:Regression testing?

[gl4ss]

well sure, but better to just remove the weird bugs in the first place than have some weird workarounds from 20 year old operating systems messing everything up..

Some (backward) progress

[WaffleMonster]

Pet peeve of mine when developers make style change thinking they are accomplishing anything worthwhile. By quantity most changes are BS to scratch itch of obsessive compulsives.

Others such as removal of jems like:

if (strlen(outdir) >= (size_t) (j ? BSIZE - j * 2 - 6 : BSIZE - 8)) {

Could be seen as progress except to accomplish it look at all extra code, memory allocation and new exception checks required to pull it off. The new code in aggregate not much better and no less complex.

Then in the same commit they just invoke asprintf as if it is no big deal with no attempt to provide compatibility for number of target platforms lacking it. This code won't even compile here anymore.

This commit is really amusing is a8d4234ebc7fd70a8e5cf34da650a6a1f89f4568

You can't make this shit up... description "ReadFile() and GetStdHandle() are not very POSIX."

These functions were ONLY used for win32 targets.

-#if defined(_WIN32) && defined(STD_INPUT_HANDLE)
-int
-raw_read_stdin(void *buf, int siz)
-{
- DWORD n;
- if (ReadFile(GetStdHandle(STD_INPUT_HANDLE), buf, siz, &n, NULL))
- return (n);
- else
- return (-1);
-}
-#else
-int
-raw_read_stdin(void *buf, int siz)
-{
- return read(fileno(stdin), buf, siz);
-}
-#endif

Their solution was to use read and write which won't even compile on win32...so the only target platform where those functions would ever be used is now broken....because why?

More totally unnecessary breakage of code for platforms they simply don't care about.

And this "OPENSSL_gmtime() is really just gmtime_r(); ok guenther"

- ts = OPENSSL_gmtime(&t, &data);
+ ts = gmtime_r(&t, &data);

More wholly unnecessary and useless breakage of platforms the committer personally does not care about. See crypto/o_time.c

Hubris in comments speak for themselves:
"remove FIPS mode support. people who require FIPS can buy something that
meets their needs, but dumping it in here only penalizes the rest of us."

Cuz not setting OPENSSL_FIPS macros is simply not enough for an obsessive compulsive.

At this point I'm done...there is no serious attempt to make OpenSSL more secure only nitpicking things you personally either don't understand or don't like.

Re:Some (backward) progress

[iggymanz]

you're confused, this is OpenBSD patching openssl that comes with that distribution. However many of their patches will help the openssl project if someone on that team can be made to have an interest in actually improving the security of openssl.

Re:Some (backward) progress

[Dutch Gun]

you're confused, this is OpenBSD patching openssl that comes with that distribution. However many of their patches will help the openssl project if someone on that team can be made to have an interest in actually improving the security of openssl.

The fact that they're starting by reformatting code and ripping out anything that's not OpenBSD/posix-compatible (e.g. Windows compatibility) seems to indicate that it's highly unlikely that this effort will be backported to OpenSSL, with the exception of very specific security fixes, perhaps. What they're doing makes a lot of sense if they're planning to fork the project and maintain it exclusively for the OpenBSD project, but I'm guessing we won't see much backpatching upstream.

If they had made these changed while preserving platform independence, it may have been a different story. They're simply doing what's best for their platform of course, so I don't begrudge them that. Obviously, the OpenBSD team isn't interested in making sure they remain compatible with Windows, etc.

I think the OpenSSL library will need it's own refactoring effort, unfortunately.

Re:Some (backward) progress

[WaffleMonster]

However many of their patches will help the openssl project if someone on that team can be made to have an interest in actually improving the security of openssl.

To say that nobody cares about security is not a serious statement. There is a difference between not getting your way and bitching publically about it and working whatever politics are necessary to gain consensus necessary to have your changes accepted.

Having looked I don't see much value in these patches. Many of them are just cosmetic and or yank functionality without a legitimate cause. I don't see where code quality or real bugs have been appreciably addressed. The sheer number of commits and lines of code changed are mostly worthless noise.

Re:Some (backward) progress

[JDG1980]

Their solution was to use read and write which won't even compile on win32

Actually, those POSIX functions do exist and work just fine on modern Windows. See here: "Functions like open, fopen, read, write and others are available in the Visual C++ run-time library."

(In case you were wondering, they work fine on MinGW, too.)

The OpenSSL code was probably written back in the Win9x days when you really did need to do things completely different on Windows. Now that the industry-standard functions are supported, why include extra, completely unnecessary cruft behind an #ifdef? The more code, the more difficult to maintain and the more potential for bugs. Some of the "Windows-specific" code in the OpenSSL code base was hacks to make it compile on Visual C++ 5.0. Do you have any idea how ridiculously outdated that is?

Re:They don't pay attention to Coverity

[epine]

You'll kick yourself later if you hit a bug that was revealed by a warning which was ignored.

Yes, it's called highsight bias, and there's an entire subfield of psychology devoted to its study, and a related subfield of behavioural economics which applies cost/benefit analysis to the human self-kick behavioural reflex arc.

There are educated self-kicks and there are also blind mice self-kicks.

Re:Quatity is not quality

[serviscope_minor]

I write provably secure code all the time in C,

What tools and techniques do you use to prove the correctness of the code? Can you point a beginner of such things to any useful resources?

Great post on another topic.

[hessian]

I disagree. Most open source projects have high code quality. For one once you have your code available for everyone to see you make a greater effort to make something decent. For another most developers I know do not like having bugs on their code. I have known a couple of occasional open source projects with poor code quality which were led by artists or other non-programmers who do not know how to do better but the number of bugs is usually less than in equivalent closed source software I know of. Documentation can indeed be a problem as since the software is constantly evolving even if someone makes the effort to document it that documentation soon gets obsoleted and useless. The best examples in documentation are usually when it is tightly integrated into the code but this is usually only doable in frameworks and other technical products like that.

This whole thing is a non-sequitur. I am speaking of the methods required to make quality software, which involves leadership and the talent (to a degree) of the people involved. It was not a jeremiad against open source software or closed source software; it's an observation about the need they have in common for strong, clear leadership.

Re:Great post on another topic.

[cheesybagel]

I have been involved in open source projects with steering boards which work just fine. You do need a clear delegation of competencies at the core level. You also need for those responsible for husbanding the project to know the code in-depth in order to judge contributions. However you are completely wrong if you think you need hermetic leadership or that there is a clear guided path to get anywhere. Linus himself called his task 'herding cats' for a reason. In open source projects code often develops organically and I see nothing wrong with that.

Competency is something that manifests itself naturally in any open source project because it is trivial for someone more competent than the original developers to fork it if they are doing a poor job at the time but they project itself still has some merit. If no one shows up and their work still stinks perhaps the project does not have a significant enough user base that warrants quality programmers to begin with.

Needs strong leadership

[hessian]

A few open source projects have high code quality. Most are mediocre programmers with an attitude of "let me join, I can code" duty-abandonment. I've seen more projects fail not far from the start because of this attitude or the "everyone is an idiot, I'm doing it my way" which is more prevalent of perl/php/python/ruby script writers. Ever notice how there are more "frameworks" for doing things in another language than there are often actual projects to use said libraries? That's about the extent of C the framework writer knows.

Not trying to contradict your point, but I think this is where the need for leadership comes in: choosing what gets done and who does it. If open source could allocate its resources more efficiently, it could do a lot better.

This, by the way, is the exact same problem found in closed-source for-pay software projects. If leadership is sloppy, everyone does what they're comfortable doing, which is usually reinventing wheels and making the "fun" parts of the code work while the other parts are wobbly.

Take this malloc issue in OpenSSL. This was an entirely unnecessary thing for OpenSSL to do, but you see wheel-reinvention repeated in things like Perl.

Can you expand on this?

Not that guy

[hessian]

A Great Leader will produce failed state software/company...

Great Leaders of the North Korean type come about because the people are so afraid of centralized power and capitalism that they support ideologues who promise equality and deliver instead Total Control.

Re:Not that guy

[Anonymuous Coward]

Great Leaders of the North Korean type come about either because they're sons of another great leader, or because they're choosen by some superpower (Russia) to run puppet-states in their "liberated" territories.

"Many eyes" did *not* find heartbleed bug

[perpenso]

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.

The quote is often misunderstood, its hyperbole. It illustrates a point nicely but in reality few users are developers and few developers are qualified readers.

More importantly the bug was not discovered by eyeballs on source code. The techniques used seem to be the same applied to proprietary closed source code. They were testing the binary.
"“We developed a product called Safeguard, which automatically tests things like encryption and authentication,” Chartier said. “We started testing the product on our own infrastructure, which uses Open SSL. And that’s how we found the bug.”"
http://readwrite.com/2014/04/1...

Re:Coding style fixes are "news" for nerds?

[DrPascal]

OpenSSH isn't.

Heartbleed != malloc

[DrYak]

hearbeats just exposed their faulty malloc replacement.

Heartbleed had nothing to do with their malloc replacement (at least not directly [*] ).
Heartbleed is just a very basic case of missing nested bound checking. (They check bounds for the heartbeat request it self, but fail to check is the super structure containing the hearthbeet - i.e.: the packet - passes the bound checks too. XKCD's explanation is actually spot-on: it's more or less equivalent to forgetting to check if the requested number of caracter doesn't exceed the size of the speachbubble).

This is not caused, by memory allocation system. This is caused by several factor, among which the fact that heartbeat are a very stupid design to begin with.
(Reasons:
- there are already other better way to keep a connection alive
- totally free payload and payload-size are a bad idea (why not simply use a fixed size 32 or 64 bits ID) ?
- specifying the payload's size is stupid, because there's already a size limit: the packet itself. Now instead there are 2 sizes to check and such redundant work often leads to errors as it happened with heartbleed)
But TLS/SSL are very convoluted, to the point that someone might ask if these standards aren't designed on purpose so someone could fuck them up. It's almost a long series of "exploit-bait" engineered into standards.

---

[*] : instead of concentrating on replacing malloc, they could concentrate on replacing another part, namely designing buffer-types that contain buffer-size and are automatically bound-checked.
So heartbleed has something to do with their in-house memory management, in that they lost the opportunity to bake automatic bound checking into their custom memory manager.

Re:Heartbleed != malloc

[manu0601]

Heartbleed had nothing to do with their malloc replacement (at least not directly [*] ).

I understand that if they had been using libc's malloc, the overflow would have been mitigated on most system by ASLR. Instead of recently used data, you would get a crash.

Re:Heartbleed != malloc

[MikeBabcock]

instead of concentrating on replacing malloc, they could concentrate on replacing another part, namely designing buffer-types that contain buffer-size and are automatically bound-checked.
So heartbleed has something to do with their in-house memory management, in that they lost the opportunity to bake automatic bound checking into their custom memory manager.

One of the few quite brilliant things DJB did was write stralloc to avoid C string issues. I wish more people would use something similar in their code.

Auditing

[DrYak]

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.

According to TFA (or even the summary), that's actually the whole point of this:
OpenSSL is currently an over complicated tangled ball of mess (though in small part this is due to the contrived SSL standard itself).
Doing code reviews on this kind of monster would be really difficult, even for a wiling company.

The point of this mass commits is to make openssl much simplier, by stripping out useless/corner case/deprecated code, and produce something whose code review could finally be within the reach of non cybernetically-augmented human being.

these 250 commits are only phase 1 of the project. phase 2 is actually doing the code review itself.

Re:Auditing

[drolli]

I dont the f**k care. If 4 developers who are probably not assigned on full time to this task taake only a week to give it a good start, then for sure a company could have taken the effort in the many years in which this library is in use.

Lack of speed leads to Firesheep

[tepples]

SSL/TLS is one of the things I don't care about speed on.

TLS library maintainers not caring about speed is part of what leads web site operators to use HTTPS for login and payment pages and redirect all other hits to HTTP.<cough>Slashdot</cough> This leaves the session cookie wide open for anyone to clone with tools like Firesheep.

Recursive Naming

[messju]

If they go straight, they'd call their fork OpenOpenSSL. :-)

Alternatively

[Fweeky]

You can also track the changes in a somewhat friendlier format using FreshBSD. Full commit messages (up to a point) upfront, more useful Atom feed, breakdown by committer etc.

Let's be clear what this actually is, NOT OpenSSL

[Y2K is bogus]

This is NOT OpenSSL they are working on, this is a private fork of OpenSSL that is intended for OpenBSD only.

They are taking big hatchets to interoperability code to simplify it, with the sole intent of targeting it at OpenBSD.

This is the walled garden approach to improving the software, only OpenBSD will have the *new* OpenSSL and it will be a non-compatible fork of the old OpenSSL.

I understand their personal motivations, but everyone has to understand that this does not make the OpenSSL ecosystem safer, it only makes the OpenBSD specific port of OpenSSL safer. The rest of the world will still be subject to any vulnerabilities and shortcomings in the code, because they are not intent on contributing this code back to OpenSSL.

That said, someone will have to further backport these changes into the baseline OpenSSL, eliminating all of the commits that remove interoperability.

Re:Open Source gone corporate?

[thsths]

> That, and that originally Linux had a semi-fascist leader in Linus Torvalds.

I am sure he prefers the term benevolent dictator. And I have to say in his favor that his leadership style has evolved noticeable over time, and that is probably what saved Linux.

The advantage of one person being in charge is of course that you get consistent leadership style, and a consistent technical direction. That often helps with open source projects - and it can be the very downfall of commercial software.

OpenOffice is an excellent example of what happens if there is no clear vision. It was elegant and reasonably simple, but not exactly pretty. Now it is neither.

Re:Quatity is not quality

[greg1104]

No dangerous construct warning would have caught heartbleed

Coverity has already come up with such a contruct warning. It is very hindsight oriented.

I'm not sure which part of your long post is the most optimistic. Belief in perfect test coverage? By definition bugs come from things you (and/or the fuzzing developers) didn't think to test. That's at least a noble goal. Can't say the same about deciding to build custom VPN software. You've got some hubris dude.

Unistd? In my Windows?

[tepples]

a platform didn't have unistd back then

Windows without Cygwin still lacked unistd.h last time I checked.

Re:Unistd? In my Windows?

[gbjbaanb]

You know you're right - VS2013 doesn't have it. I was sure I'd had to use it recently, but just checked and you're right.

Oh well, back to macros :-)

Go OpenBSD

[mveloso]

Reading their comments makes me want to install OpenBSD for more of my machines down the road. These guys seem to be thinking the right way about things.

Re:Kill the monster

[maugle]

Be careful. Advocating a from-scratch rewrite, instead of fixing the broken parts of a mostly-working system, is the hallmark of a CADT development model.

Alternative to opening admin port to world?

[tepples]

Say I need to administer a server from home, from the home of a relative that I visit every other weekend, occasionally from public Wi-Fi in a restaurant or library, and rarely from public Wi-Fi in a hotel in another state. Other than opening the server's SSH or HTTPS administration port to the Internet, what other method would you recommend for me to log in and do work from all of those places?

Re:Alternative to opening admin port to world?

[TCM]

OpenVPN with --tls-auth protecting the TLS layer. That protection made OpenVPN safe against Heartbleed. Doesn't work if you have untrusted users, obviously.

Don't VPN directly into your LAN. Use a hardened node in a heavily firewalled DMZ and use SSH from there.

OpenVPN and OpenSSH simultaneously having a vulnerability is pretty unlikely.

Re:Alternative to opening admin port to world?

[tepples]

So which hosting company do you recommend that offers SSH over VPN? Shared hosts that I've seen offer only a web-based administration panel and a shell account. With VPS or dedicated, you'd have to rent two servers: one to act as the "hardened node in a heavily firewalled DMZ" and one to actually be the server administered through SSH. And even then, how would you administer the "hardened node in a heavily firewalled DMZ"?

Re:Alternative to opening admin port to world?

[TCM]

My bad. Somehow I was assuming the server is in your home LAN.

Re:Alternative to opening admin port to world?

[tepples]

In that case, that's sort of what I already do. One of my bosses has a Windows machine and a Linux machine in his home office, and the only forwarded port is SSH on the Linux machine. To connect to the Windows PC, I tunnel RDP through SSH.

Re:Alternative to opening admin port to world?

[smash]

I would suggest setting up a tunnel of some sort to a DMZ and only allowing SSH from there. I need to remotely administer my network myself, and I don't expose SSH to the internet. Way too many script kiddies are poking at SSH all day.

Open source is not unpaid labor

[mbkennel]

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

Open source doesn't have to be unpaid. Though often it is.

Re:What's with the @s?

[TCM]

It's a common notation among official OpenBSD developers to refer to individuals by their mail user name - without the openbsd.org domain. You see it in almost every commit and in mails when the person's role as an official developer is emphasized.

beck@ vs. @beck; M$ vs. $M

[tepples]

It's like Twitter, only backward, in the same sense that BASIC string variables are like shell, Perl, or PHP variables, only backward.

Microsoft doesn't give a fork()

[tepples]

The OpenSSL code was probably written back in the Win9x days when you really did need to do things completely different on Windows. Now that the industry-standard functions are supported

I was under the impression that fork() was still broken outside Cygwin.

OpenBSD's version of OpenSSL will be

[billstewart]

We'll see if they can get the original OpenSSL project leaders to accept their changes, or whether they'll end up with their own fork of the project.

And while OpenSSL isn't an OpenBSD project (unlike OpenSSH), it's a tool that OpenBSD uses.

Re:OpenBSD's version of OpenSSL will be

[Yaur]

My understanding is that this is a pretty hard fork where the first order of business was removing the ifdefs that weren't needed for OpenBSD.

Re:OpenBSD's version of OpenSSL will be

[xdor]

Got the master "development" branch from OpenSSL. No sign the OpenBSD guys have been doing anything there.

So all of these commits must be happening on Theo's system. Looks like its only a fork, for now.

SSL speed used to matter a lot, still does

[billstewart]

SSL has two parts that take a lot of time - key exchange using public-key technology, which just depends on the number of connections, and data encryption, which takes time proportional to the amount of data encrypted. Until the last few years, the key exchange time dominated, because public-key operations are slow and most use of SSL was for encrypting passwords, credit card numbers, or other very small chunks of data. It was pulling teeth to get a lot of sites to use SSL at all (though the whole Certificate Authority system is a lot to blame for that), and it was pulling teeth to get a lot of sites to encrypt more than just your login and credit card data (such as the whole page that asks for your login.)

Do you think speed doesn't matter any more, now that lots of sites are running with the CPU relatively idle? How many SSL connections do you use where the server has bothered to turn on PFS, the Perfect Forward Secrecy stuff that does a one-time Diffie-Hellman exchange? (Appallingly few.) How many sites do you connect to that are using 2048-bit public-key or longer? (Some, but hardly most.) It's still about performance.

Re:Open Source gone corporate?

[Barsteward]

"Semi-fascist" - ????

Libreoffice does the job for me, not sure what you mean by "workable piece of software" in this context.

Re:Let's be clear what this actually is, NOT OpenS

[tyrione]

So? Apple was smart enough to move off of OpenSSL and started telling developers to do so in 2007. iOS doesn't support it. Apple's new frameworks are the reason OS X and iOS are not susceptible to this, unless someone intentionally installs OpenSSL from Ports or other 3rd party add-ons which applications installed require using it. I'm thinking FreeBSD will be modeling OS X's solution sooner, rather than later.

Re:Let's be clear what this actually is, NOT OpenS

[styrotech]

I understand their personal motivations, but everyone has to understand that this does not make the OpenSSL ecosystem safer, it only makes the OpenBSD specific port of OpenSSL safer. The rest of the world will still be subject to any vulnerabilities and shortcomings in the code, because they are not intent on contributing this code back to OpenSSL.

While you are correct (for now), you're not thinking far enough ahead. I reckon a year or two down the road there will be a portable version of this library just like what happened with OpenSSH when they forked SSH for themselves. ie OpenBSD becomes the new upstream for libssl rather than the existing OpenSSL team.

There is a reasonable chance the portable version of the fork could eventually end up taking over from OpenSSL by default on the other BSDs and some Linux distros.

Re:Let's be clear what this actually is, NOT OpenS

[whogivesafuckingfuck]

Do you know how many of the interop code paths are untested, totally irrelevant on any modern system, and probably broken? Do you understand that when the OpenBSD developers review, clean up, and change the surrounding code, the ifdeffed code parts that cannot be tested on OpenBSD will detoriate further and break even more than they are broken already? Do you know that there is a better way to port software to crappy OSen than making critical sections a ghastly jungle of #ifdef? That code really needed to go. It would only get in the way otherwise. Once the code base is cleaned up, it shouldn't be too difficult to take it make a -portable version to run it on other OSes. Believe it or not, they do not need or have that many nonportable OS-specific things in crypto code. At least one bug discovered on OpenBSD (after heartbleed) has already made it to other systems with OpenSSL. So quit spreading bullshit about the OpenSSL ecosystem not becoming any safer.

Re:rewrite it from scratch

[whogivesafuckingfuck]

Why don't you do it. See how you far you can make it.

You severely underestimate the amount of work a clean reimplementation would require.

And what is wrong with fixing crappy code?

Re:Open Source gone corporate?

[cheesybagel]

OpenOffice was started as StarOffice and hence began as a closed source software product from a German software house called StarDivision. So I find your comment interesting to say the least.

Boundchecking

[DrYak]

Yup, that is indeed what's missing inside something like openssl.
Throw in a secure compare in way that doesn't cause confusion (i.e.: avoid's openssl's CRYPTO_memcmp vs OPENSSL_memcmp. If you really need the later, call it something unambiguous like "leaky_memcmp"), and bound checked substring copy, and you have basically covered all needs of a crypto library.

comprehension fault

[DrYak]

Okay perhaps I've misinterpreted the initial state.

I've understood it as "Heartbleed is an exemple of bug provoked by their malloc replacement"
(which is wrong. heartbleed is caused by a buffer overrun in an unchecked pointer manipulation. malloc isn't the cause).

Not as "the investigation of the heartbleed bug has showed that their malloc replacement is bad"
(which is indeed correct: their malloc replacement prevents using secure feature that would be able to detect problems like heartbleed. In "openssl valhalla rampage"'s own terms they have "exploit mitigiation"-mitigiations.)

They need to look into this

[nctritech]

Not fixing things fast enough, kids: http://pastebin.com/qPxR9BRv