True, most of my experience is with companies 10k, but you're just being arrogant calling that "really small". Almost all of those companies are part of a larger corporation, and you don't manage IT operating activities in multinational corporations on the corporate level. The corporate level decides if you go with SAP or Oracle, but not which patch level of Apache is used on the website of one of 20 subsidiaries.

At least that's the way it was in my last two companies (one a subsidiary of a 65k employee corporation, one part of a 30k employee corporation). If you know of any multinational corporations where the CTO of the top-level holding has to sign off on patch deployment, let me know.

We're talking operative emergency response here, not rollout of new corporate IT infrastructures. I hope you see the difference.

You're cute. I've done this shit for a living for a while. Yes, many companies' incidence response procedures are crap, but they shouldn't, and it is perfectly possible to get an emergency countermeasure deployed within 24 hours with all the t's crossed and i's dotted and perfect SOX compliance and whatever else you need. It's just something you need to think about before the emergency hits you.

Of course everything else is never equal.

But what are you trying to accomplish here? Argue that a project with 100 developers has more eyes on the code than one with 4? Moot point, no argument.

We don't get the luxury of having 50 identical software projects with different team sizes and a size control, so we have to go with the real world and "everything else being equal" is just a way of saying that you if you want to compare closed vs. open source, you need to compare comparable projects, not an open source project with a handful of people with a closed source project two orders of magnitude larger - or the other way around.

There's a difference?

sysadmin, firewall admin - let's not pick nits here. The point is that there are mitigating measures, and if signing off on something that prevents your company secrets leaking out to the Internet without you even noticing takes more than 24 hours then your incident response procedures are retarded and you can hire me for a workshop to improve them dramatically.

Yeah, there was absolutely nothing anyone could do. Oh wait, except for this brutally complex and technically challenging thing right from the official vulnerability announcement:

That was definitely not a feasabole option for anyone on the planet...

You are right on those.

Except for the "nothing can be done" part. That's not your judgement call to make. There is always at least one option - pulling the power plug - and it might well be a feasable temporary solution for some people affected.

Absolutely.

But we were talking about mitigating measures. That is almost never patch and recompile, it's things like turning off a service, changing the firewall rules, moving servers into a different network - things that are very much within the duties of the sysadmin (with proper clearance and risk acceptance by management, etc. etc.)

Basically, if you have a bug that makes your internal network open to the world, but you can avoid it by disabling feature X in the config file, and your company doesn't require feature X, then that's something the sysadmin can do, and he can do it right now, while the vendor is working on a patch.

I agree on that 100%

That depends a lot on the particular problem. In many cases, there are mitigating measures that can be taken until a patch is available, and I'd argue strongly that the people affected should make the call on that, not you or I or anyone else.

By withholding information, you are making decisions for other people. But you are not in a position to make that call, because you are not the one who suffers the consequences.

I advocate for giving everyone all the information so they all can act according to their needs and abilities. I argue for letting people make their own decisions.

See other reply.

Yes, of course, a closed source development that does external code reviews can have more eyes on the project then an open source development that does no external code reviews. But then you're comparing apples and oranges.

I didn't see it's the thousands of eyes that fanatics claim.

I'm simply saying that if your source code is open, your number of eyes on the project is (dev team) + (people looking at it) while for a closed source project the number is (dev team).

Since "people" cannot be negative, by necessity (dev team) + (other people) >= (dev team)

It doesn't.

It does guarantee that the number of reviewers is equal to or higher, provided everything else is equal.

Yes, this argument is being made a million times and it doesn't prove anything because it rests on so many assumptions that may or may not be true that it's total truth value is about as good as tossing a coin.

The two most important:

First, you assume that the official patch is the only thing that can be done. In many, many cases there are other (temporary) measures that can be taken to mitigate a problem or limit its impact. Who are you to decide for everyone on the planet with their different needs and scenarios which is better?

Second, you assume that there are thousands of hackers who didn't know about it. Yes, it is likely that the number of bad guys knowing about the problem was less than 100% before the announcement. But any real professional doesn't care about number of hackers, he cares about risk, which is number multiplied by impact. If the people who are the worst danger to my business and are most likely to target me already have the exploit, I don't give a fuck about a thousand random script kiddies also getting it.

Depends, but yes for many non-essential services, that is indeed an option. Imagine your actual web service doesn't use SSL, but your admin backend does. It's used only by employees on the road, because internal employees access it through the internal network.

Sure you can turn that off for a week. It's a bit of trouble, but much better than leacking all your data.

Or if it's not about your web service, but about that SSL-secured VPN access to your external network? If you can live without home office for a week, you can turn that off and wait for the patch, yes.

Most importantly, who are you to decide that everyone should wait for a patch instead of giving people the opportunity to deploy such mitigating measures?

People don't learn.

We used to do that.

Full disclosure evolved primarily as a countermeasure because vendors took those grace periods not as a "we need to get this fixed in that time", but as a "cool, we can sit on our arses doing nothing for another two weeks".

My preferred choice of being left alone or being beaten to a pulp is being left alone, not some compromise in the middle, thank you. Just because there are two opposing positions doesn't mean that the answer lies in the middle.

I've given more extensive reasoning elsewhere, but it boils down to proponents of "responsible disclosure" conveniently forgetting to consider that every delay also helps those bad guys who are in posession of the exploit. Not only can they use it for longer, they can also use it for longer against targets who don't know they are vulnerable.

Many, many companies run non-essential services that they would not hesitate to shut down for a few days if they knew that there's an exploit that endangers their internal systems. Other companies could deploy mitigating measures while waiting for the patch.

Don't pretend sysadmins are powerlessly waiting with big eyes for the almighty vendor to issue a patch.

There's a black market where you can buy and sell 0-days.

Sure you give it to more people (and for free) than before. But the really dangerous people are more likely than not to already have it.