I saw those slides. There were 17 levels of #ifdefs in the code. Every ifdef is a binary switch, which means 2^17 different iterations of source code.(!!!!!) That's 131072 different compiles (!!!!!!).

So, lets pretend that a config/make sequence just needs 10 minutes (unlikely, they have an oddball config script that isn't like autoconf). To hit 17 levels of ifdef, you'd need approx 910 computer-days just to do all the compiles. Do you think they tested this matrix?

I hate to beat up on a bunch of people who did hard work for free, but they really did a bad job on a lot of things.

Add to that the "oh my god we gotta copy _____" about the new USB C connector. You can flip it, just like a Lightning connector. But yet another micro connector.

And don't get me started about the "full speed" "high speed" "Higher speed" mess that is 1.0 2.0 and 3.0 speeds.

Im in Chicago, meaning Illinois.

A few years back, a cop got shot on a traffic stop. The driver pulled a gun, the cop couldn't see it, window tints. So, soon there was a state law saying o window tints, at least in front windows. That said, i see a lot of cars that have them, so not sure if the law is still on the books, or whether cops just ignore it. I'm sure if it's still on the books, it's not enforced equally black/white.

If you check the slides, there are a few areas that they failed hard on. I don't know if you're a C developer, but I've coded a bit, and the slides scared me a bit.

Yeah, there was the "cross platform" stuff. Do we really need EBCDIC support? There's a simple rule about code. If you can't test it, you should pull it. Do you have a machine you can test on? They had Win32 Winsock code, which is a special case. But all modern Windows computers have a Berkely sockets type stack. This doesn't need special code, which means a lot less code to debug.

When the OpenSSL guys state (with some justification) that they have no resources, part of the problem is they waste it by having unused code paths. They'd save some testing time by having removed this code before.

But they also did "cross platform" it badly. They had their own printf, when printf has been done and safe for years. But just in case on some oddball platform, we have our own. They had 17 levels of nested #ifdef. If you don't know C, that's SCARY. There's no way you'd unwind that in your head, and there's near zero chance you'd be able to code a test plan for that. Why? Because you can think of #ifdef as a way of doing simple code modification... 17 levels deep of this type of modification is near impossible to think through and is nearly guaranteed for bugs.

Worst of all, in name of one platform, they came out with an oddball memory allocator. They added things to this allocator to the point where they couldn't run a normal one. Worse off? They got so used to BUGS in this allocator that they couldn't move off of it. And these bugs are directly related to the Heartbleed bug - it's a memory management bug. Instead of thinking "hey, we're doing a lot of weird stuff just for this odd platform" they made the decision "hey, lets go even deeper down the hole of bad code"

So, in name of "cross platform" they had many many design mistakes, including something that broke much of HTTPS. I wouldn't use "they were doing cross platform" as an excuse for their mistakes, because in this name, they had made much of their mistakes.

This wasn't in some text editor. This was in a piece of core crypto. The level of sloppiness allowed is zero.

They OpenBSD folks take their tone from Theo De Raadt, who generally is one of the ruder people out there. When i first heard the rants about OpenSSL, i was thinking "well, they didn't have to smack them down so hard." After reading the slides, Im thinking "yeah, I'd rant that hard" though i don't have the same Forum as the LibreSSL guys have.

Plus, it's better to have multiple libraries.

This is not a universal good. There is a cost to:

* Choice. Now I need to figure out which is better. This is why Amazon has reviews - choice makes things difficult.

* Diffusion of resources. Part of the reason OpenSSL was so bad was that this team had no money and no resources.

There are a lot of projects out there, forks for spite, forks for license religion, that are a waste of time and resources. "Oh ____ has a free software license, but it has slightly different focuses of types of freedom, therefore it's heresy. Hey, here's GNU____. We know you'll ignore the bugs/missing features, because FREEDOM"

1) that CO2 would be poisonous?

Water in sufficient quantities is toxic. I don't even mean in the drowning sense, or the silly DiHydrogen Monoxide jokes, but if you have too much water, it can kill you.

Nitrogen also works this way. Nitrogen in air, normal pressure, is fine. Nitrogen under pressure can kill you.

Too much oxygen can make you space out.

There are a lot of things that follow this - if you think of normal doses of heat, or electricity, you're fine. If too much, you die. It doesn't take a lot of thinking to come up with examples.

Though I don't know the exact mechanism, I'd say to watch Apollo 13. Watch how much effort they put in to the CO2 scrubbers, to remove carbon dioxide from the air. They had sufficient oxygen, it was the CO2 levels that were too high. That's what was making them sick.

My tough guess here is something like valgrind would have helped. Yeah, even though you have the limits of true brk() allocation bundles, valgrind operates more at a byte level. Valgrind in this case would have been useless, because of the custom allocator code.

if you write code that requires a "caching" allocator so much that you break with normal malloc()/free(), you're doing something wrong. If you're doing it in high impact security code, you really should stop everything else and fix what you're doing wrong.

If I'm a malicious hacker, or the NSA, but I repeat myself....

I'd be now (if i wasn't before) checking the feeds for gnutls, nss,, and openssl, hoping to catch he bug before anyone else, so i can exploit it.

That said, I'd also be checking out the best decompilers to see if that helps me find bugs in closed source code. Im sure people have looked online for Windows source code to see if there are any ways to exploit it. In this case, a small group of hackers would have the code, and would necessarily want to limit the number of people aware of those exploits.

In a nutshell, we're all screwed.

Don't most people who complain about mods get metamodded to smitherines? This guy is complaining about moderation (being in the form of popularity and talk) about something.

I'd get metamodded to shreds, he gets a front page post.

Wasn't this on Colbert?

"Who knew that a bunch of college kids would put things off until the last minute" or something to that effect.

is it any better than a billion geeks in Silicon Valley trying to create YetAnotherMobileLocationCheckin platform? Today Facebook, yesterday, Foursquare.

The market wants what it wants. Capitalism never claimed to fund the most useful thing.

If you have root on a webserver, why do you need javascript to do the redirect?

Lets say you had root, to get a redirect in apache you'd need to:

* edit the config file, bounce the server as root, leaving a change in the config and a bounce record in the server log
  or
* create a .htaccess file, possibly edit the config to respect the .htaccess file and the subsequent bounce as root, leaving possibly a new file on the filesystem that can be detected
  or
* edit a javascript file that's likely to be around and edited anyway.

The latter is most likely to evade detection. Besides, no one said they had root.

From the comments on the announce page, since (almost) nobody will go over there.

The first site on compromise_1.txt seems to be running “Apache/2.2.26 (FreeBSD) DAV/2 mod_ssl/2.2.26 OpenSSL/0.9.8y”, which does not quite sound like it’d be running Linux at all. As others have already pointed out, I would not blame this on a Linux kernel bug yet.

So, it looks like the "old 2.6.x kernel releases" was really just a signal for "old nonupdated code".

BTW: for those who bitch about "well the 2.6 line was patched and maintained all the way to 2011" they do have a line where they imply the 2.6 kernels are early kernels, not the latter 2.6.20 whatever ones, but it's not a well written article and is easy to miss.

... #ThankYouDayton...

I've been lucky enough to go to Dayton for a tournament. It was so loud they disrupted our cheerleaders. Even during off times they were still so loud our cheerleaders couldn't hear the beat to do their routines.

They're freaking nuts about basketball. I wouldn't have necessarily picked them to win over Ohio State, but I'm not too shocked that they did.