Apparently you have not heard about companies that collapse if they are offline for a day or so. But then, with the level of stupidity your answer displays, you would not have...

And to amplify it in the meantime. Well done.

Not really. Disabling the patch took changing the sources manually and rebuilding OpenSSL, something most sysadmins cannot do or cannot do fast.

I think the main problem with the flavor of responsible disclosure some part of the security community is raging against is that this flavor allows the developers to say how long they need, and that has been abused. But giving them zero time is just malicious.

Sorry, but that really is nonsense. All that immediate disclosure can cause is panic. It does not help at all. It increases attacks in the short-term, because most people are not able to do anything without patch.

Sure, you can argue for very short time given to the manufacturer, like a few days (they will not make that large a difference for the ones already using the weakness, most weaknesses exist for quite a while before they are discovered by the white-hats and analysis also takes some time), and some companies have been abusing responsible disclosure by delaying fixes for months and months, so I am all for that. The thing is that the manufacturer must not be the one to set the time they get to fix this. But giving them zero time is just intentionally destructive.

I don't.

That is BS. You are mixing two things to make your non-existing point: People that want to disclose and people that want to sell. The second ones are always black-hats, even if some of them pretend otherwise.

All to make a quick buck. Despicable and repulsive.

Indeed. But there is a _standard_ solution. Doing it in various ways is far worse than picking the one accepted bad solution.

Mindless propaganda and, as it happens, untrue. See for example http://developers.slashdot.org...

But I guess proponents of closed source will always use any lie that is handy, just to propagate their ideology.

The only possible way is to disclose to the responsible manufacturer (OpenSSL) and nobody else first, then, after a delay given to the manufacturer to fix the issue, disclose to everybody. Nothing else works. All disclosures to others have a high risk of leaking. (The one to the manufacturer also has a risk of leaking, but that cannot be avoided.)

The other thing is that as soon as a patch is out, the problem needs to be disclosed immediately by the manufacturer to everybody (just saying "fixed critical security bug" is fine), as the black-hats watch patches and will start exploiting very soon after.

All this is well known. Why is this even being discussed? Are people so terminally stupid that they need to tell some "buddies"? Nobody giving out advance warnings to anybody besides the manufacturer deserves to be in the security industry in the first place as they do not get it at all or do not care about security in the first place.

Like, say, placing the emergency generators on the hills right next to it, nothing bad would have happened. Of if they had spend the extra $100.000 that would have cost for hydrogen valves, the buildings would not have exploded.

The problem is not that nuclear cannot be made safe. The problem is that the people doing nuclear cannot make it safe. And as these are also the people doing waste storage, this will remain a serious issue for the next, say, 1 million years or so. The combination of greed and stupidity found in nuclear planners is absolutely staggering.

You are right of course, the incentive-structure is completely messed up. For example, if Microsoft had to pay for all the losses their crappy products causes, OS/2 would never had had the marketing issues that killed it. Or if the ones using FOSS but contributing nothing would have to insure themselves against losses due to errors in FOSS from a certain level of usage intensity onwards.

The problem is that short-term-cheap is not anything that can ever work for things that need to be secure or reliable. And that the people making the decisions for what to buy are idiots or egoists (often both) and do not have to shoulder any of the effects of their bad decisions. Power without responsibility. That can never work. Most people will always optimize their short-term gains, because they do not understand or do not care about the long-term implications.

Indeed. Devs in large organizations cannot even talk to system administrators anymore these days (or rather they are forbidden to do so). And Sysadmins cannot talk to networking, and networking cannot talk to firewalls, and so on.

I have just recently had a project, where the application ops team was only allowed to talk to the network people directly in case of a dire incident. Yes, they knew who they where, had their phone numbers and had a working relationship. But the contracts enforced all communications to go through 1st level support and these people reject all things that are not immediate problems. Whoever thought that set-up would be a good idea should be fired on the spot. Instead, that idiot probably got a huge bonus for messing this up completely. One of the results is that when there are smaller network troubles, or when planning is to be done, things are delayed until there is a serious incident, because only then people that need to talk to each other are allowed to do so.

I disagree. Full control is the only way to enforce KISS. KISS is the only way to write secure software. Sure, a Garbage Collector, for example, sounds nice in theory, but in practice it is merely a tool that allows people that are too incompetent to do memory management to still use dynamic allocation. For example, with a GC you can never be sure freed memory is wiped before being re-used and that can change from one release to the next. Fully checked containers sound nice, but often it turns out they are not that fully checked, or have other limitations and bugs and quite often are not even fully documented. Talk about accidents waiting to happen. Only if you do them yourself can you be sure they indeed do what you think. And so on. I used to be a proponent of high-level languages for everything myself. Bit from what I have seen, they just make the problem worse when security is important.

Sure, if you do complex software, all these features help. But if you do complex software, it will be insecure. One thing that a language like C makes a lot easier is KISS, because as soon as you find you have to jump though hoops, you notice that you may be doing it wrong and too complex. Of course, if there were an alternative to C in low-level programming, that one would be just as viable. Since C is unique (unless you want to program assembler, that is), it has a special place. This may look like a "be-all hammer", but it is not and that is not the point.

Of course you should always strive to encapsulate the security-critical functionality and make it as small as possible (by KISS). Writing the rest in some modern language is perfectly fine and I am not arguing against that.

But the bottom line is that if the coder is not able to use full control competently, the coder is not qualified to write security-critical software. Mos coders are not qualified to write security-critical software, as we are seeing daily, no argument there.

As languages and tools are fundamentally incapable of "fixing" limitations of the people using them, I guess you are on the left-side of the Dunning-Kruger graphs as well. There is no replacement for a person that knows what he/she is doing. None at all. There never will be. Making this a language issue just serves to get more people into positions they are filling incompetently. They will then have negative performance, because they cause more problems than they solve. Building software with people that do not have what it takes is not economically viable, unless you are immoral scum that first establishes a monopoly and then puts all the cost of the broken software on the customers. Like Microsoft is doing for example. That is one reason why monopolies are incompatible with capitalism.