Because it's a tiresome, tropey, and ultimately invalid complaint. Look downthread at the person who said the FreeBSD commit log was better than this page, despite being inscrutable to security practitioners who don't work in the kernel and not saying a word about proven exploit vectors.
These complaints aren't about what's better or worse for the user community; they're about people trying to put vulnerability researchers in their place.
It's not even a complete description of the vulnerability. It's what the kernel maintainers need to know to understand and fix the bug in the code. The claim that it's superior to the branded vulnerability page gives away the whole game.
Why not? This weird complaint has been happening since ~2010 and it has never made any sense. You are strictly better off with the website than without it. When it was vulnerability researchers getting all peevish about the status competition they were running, I at least understood where the complaint was coming from, but even among practitioners, branded vulnerabilities are so much the norm at this point that there's no status implication anymore.
Is that even the fix though? The problem sizeof*groups expression has already been removed by that point. This fixes something but it's not obviously related to the vulnerability description.
No, that commit log is obviously not better than the page explaining the vulnerability and the exploit vectors.
Case in point: what's "tired" about the stack exploitation techniques they're using here?
And, while you're not right, even stipulating that you were, what would that matter? How is anyone better off with less explanation of a vulnerability?
Is there something in this website that feels unnecessary? It seems like a good format of sharing high quality information.
This looks like a full bug into a complete root escalation of a kernel. That's hard to do and deserving of praise. The fact that we have a writeup organized like this is awesome.
-------
This is sort of the expert level stuff that I thought HackerNews would most enjoy.
You're not going to get anywhere in the security sector unless you gain notoriety i.e. are noticed.
This appears to come from dressing up like Elton John in a feather suit and hiring a marketing team.
It's a wall of text about a kernel stack overflow. I'm not sure where the "Elton John" part is. Is it... that they used an accent color?
Buffer overflow.
Maybe the researcher was wearing windshield-wiper spectacles when he discovered the vulnerability.
I don't understand why you're being so defensive about this.
Because it's a tiresome, tropey, and ultimately invalid complaint. Look downthread at the person who said the FreeBSD commit log was better than this page, despite being inscrutable to security practitioners who don't work in the kernel and not saying a word about proven exploit vectors.
These complaints aren't about what's better or worse for the user community; they're about people trying to put vulnerability researchers in their place.
While I believe whimsical names will always be silly, I do concede that commit log is effectively useless to 99% of eyeballs.
It's not even a complete description of the vulnerability. It's what the kernel maintainers need to know to understand and fix the bug in the code. The claim that it's superior to the branded vulnerability page gives away the whole game.
It gives legitimacy to whatever whimsical name was given to a vulnerability by registering the domain.
CVE numbers are for boring professionals.
The cool kiddies wait and time their disclosures on the cool numbers.
Why not? This weird complaint has been happening since ~2010 and it has never made any sense. You are strictly better off with the website than without it. When it was vulnerability researchers getting all peevish about the status competition they were running, I at least understood where the complaint was coming from, but even among practitioners, branded vulnerabilities are so much the norm at this point that there's no status implication anymore.
> You are strictly better off with the website than without it.
Why? This is a better resource in every way: https://cgit.freebsd.org/src/commit/?id=000d5b52c19ff3858a6f...
It details the actual problem instead of showing off tired stack exploit tricks.
Is that even the fix though? The problem sizeof*groups expression has already been removed by that point. This fixes something but it's not obviously related to the vulnerability description.
git log -S suggests 4cd93df95e697942adf0ff038fc8f357cbb07cf9, which looks more likely: https://cgit.freebsd.org/src/commit/?id=4cd93df95e697942adf0... - though not to say you don't want the later commit too. I'm sure you do.
No, that commit log is obviously not better than the page explaining the vulnerability and the exploit vectors.
Case in point: what's "tired" about the stack exploitation techniques they're using here?
And, while you're not right, even stipulating that you were, what would that matter? How is anyone better off with less explanation of a vulnerability?
Have you not done anything remotely interesting for you that you want to build a website so the whole world can see it?
[dead]
What?
Is there something in this website that feels unnecessary? It seems like a good format of sharing high quality information.
This looks like a full bug into a complete root escalation of a kernel. That's hard to do and deserving of praise. The fact that we have a writeup organized like this is awesome.
-------
This is sort of the expert level stuff that I thought HackerNews would most enjoy.