> In computer security, coordinated vulnerability disclosure (CVD, sometimes known as responsible disclosure)
I guess you can learn something new after 36 years.
If you are referring to what you quoted, your pedantry and sharpshooting would result in an incomplete English sentence: "that's why we have the responsible disclosure" is missing a noun. Now that we are firmly in worthless pedantry:
Protocol (n):
1.a. a system of rules that explain the correct conduct and procedures to be followed in formal situations
1.b. a set of conventions governing the treatment and especially the formatting of data in an electronic communications system
If you don't like what I said or disagree, poke holes in factual inaccuracies. However, in the reality that I am pretty sure we all share, responsible disclosure is a well established protocol that is followed by many security researchers, and was imperfectly followed here.
These researchers found a vulnerability in the Linux kernel. They could have just written a blog post and put it online, or not told anybody, or sold it. But instead they decided to tell the Linux kernel devs, and give them time to act before publishing.
And your beef is that you’ve decided they needed to also inform individual downstream projects that use the Linux kernel? Why? Which ones?
No, it's commonly followed practice: https://en.wikipedia.org/wiki/Coordinated_vulnerability_disc...
I'm all for lighting a fire under the developer's ass, but we live in an imperfect world and the biggest problem that we have is end-users. We may have applied the mitigation on day 0, and updated as soon as the kernel landed in our distro - and if some of us didn't then we've even got savvy users in that "don't update fast enough group" (which is fine, which is human, but is said imperfection).
Major distros should at least have gotten a few days of notice for something this catastrophic. It doesn't help that the kernel is fixed if "normies" aren't able to access it on day 0. For reference, the standard is 30 for the developer to fix and 90 for it to land on machines. Even 30+7 would have been a substantial improvement.
Ethical security research involves ethics, and maybe they aren't referenced in university/college any more - but here's what I was taught: https://www.acm.org/code-of-ethics .
> 1.1 Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing.
> [...] Computing professionals should consider whether the results of their efforts will [...] and will be broadly accessible.
> 1.2 Avoid harm.
> (Honestly, all of it)
> 2.3 Know and respect existing rules pertaining to professional work.
> 3.1 Ensure that the public good is the central concern during all professional computing work.
> People—including users, customers, colleagues, and others affected directly or indirectly—should always be the central concern in computing.
Maybe other code of ethics for CS exist; I'd like to know which ethics these ethical researchers were following.
Please don't put words in my mouth when I have clearly stated the contrary. I used the word "disclosure," that is very different to keeping things secret.
> For reference, the standard is 30 for the developer to fix and 90 for it to land on machines.
I’ve never seen that as a standard anywhere.
Are you thinking of this? https://projectzero.google/vulnerability-disclosure-policy.h...
Nobody, for what it's worth, is arguing that major distros shouldn't have gotten some kind of notice. The problem is that the entity responsible for doing that isn't the vulnerability research lab. In fact, as a general procedural point, researchers can't go contact downstreams. They might be able to do so in the specific case of Linux, but you've tried to spin that possibility into a binding obligation derived from established practices, which: no. That's not a real thing.
I never said "binding obligation," that is the first time "binding" has appeared in this discussion and was introduced by you. Once again claiming things I have never said. Doing what you are free to do can still be a shitty thing to do.
I am a bluffing moron who knows nothing, you win.
no, the standard is 90 days from notification or 30 days from the patch date, typically whichever is sooner.
e.g.
> If a vendor patches a security issue 47 days after Project Zero notified
> the vendor about the vulnerability, details would be made public on day 77.
> If a vendor patches a security issue 83 days after Project Zero notified
> the vendor about the vulnerability, details would be made public on day 113.
please also note that you are blindly quoting wikipedia articles at people who either currently work in security research, or used to work in security research. while we are not infallible, you should perhaps consider that we at least have real life experience dealing with vulnerability disclosure processes, and arent just learning about them today from wikipedia. when a room full of experienced professionals are telling you that you are misunderstanding something, that is a sign to step back for a second and maybe reconsider your position.> There is no such thing as "the responsible disclosure protocol".
And yes, I admit I got dragged down to their level and beat myself with a dumb stick in the process.
Or do you rely on the OpenSSL project to work their established process?
> You: No, I wouldn't, because my own preferences are towards immediate disclosure.
And there it is. You could have said "I don't think responsible disclosure is a good idea" and moved on, but now we have whatever the fuck this is.
Bluffing sure as hell beats incapable of being wrong. I'll take it.