But you did. What the communication accomplished was getting others who otherwise might not have heard about or cared enough to do something to take measures in fixing it.
That's an enormous win.
That's an enormous win.
I think that cost is outweighed by the significant increase in exposure.
I'm not saying to make it difficult for people to understand the root cause. We should strive for both. But if I had to choose one over the other I think for a bug this big that marketing it as such wins.
The long tail.
Normally, to get out of the standard sysadmin patch rut and into an expedited state, your bug needs to convincingly cough up code execution. Since this bug didn't do that, but was nonetheless very severe, it makes perfect sense to me that additional marketing was required to expedite fixes.
It's among the most widespread Internet bugs, but:
* An identical bug impacted nginx a few years ago
* A far worse bug impacted Debian (when they commented out the randomness in their CSPRNG), which coughed up code execution on tens of thousands of machines; lots of companies that didn't officially deploy on Debian still had a Debian box somewhere vulnerable
* The Rails YAML bug was perniciously exposed in lots of places for months after the initial disclosure, and also coughed up code execution
Losing authenticators for "live" users and TLS private keys is bad, but it's not the kind of bad where you invariably need to nuke your servers from orbit and rebuild. Other widespread bugs were actually like that.
Compared to what? Awareness and server-side adoption of fixes for issues at this level of criticality is not a problem our industry has.
A problem we used to have, however, is people engaging in grandstanding and irresponsible disclosure, leaving users insecure and catching the industry flat-footed.
Empty scare marketing is a solution to a problem we don't have. It's also a great tool for self-advertisement, and I can only assume that's why patio11 jumped on it.
I probably don't agree with that. I think there are plenty of systems in our industry that aren't actively maintained and don't have dedicated ops to manage them. A fix to a bug this large in magnitude needs to find their way onto those systems.
I refer you back to this recent article, which was also discussed extensively here: http://arstechnica.com/security/2014/03/ancient-linux-server...
'Our industry' is not just the parts people are proud of, it includes a multide of craptacular bit players that nevertheless participate in the information economy.