Nah, c suite was pretty clearly in the right here. Dude left because he was pissed that a vulnerability got assigned a CVE instead of just… Not informing anyone so they could quietly fix it.
Have you looked into the CVE? Apparently it is a non issue. You could use it to dos a service that have an experimental feature enabled, which is disabled by default, on a non stable Version. I understand the dev. CVE should be for serious issues. And they alerted their users over an email list
It can be used for dos, as it is crashing workers, but they will be restarted anyway.
There is an astounding number of lies in your post, good lord.
It is an issue. A DoS is a fairly serious vulnerability, and very much is a vulnerability.
Experimental features are explicitly defined to require their vulnerabilities to be assigned CVEs.
It is not just available on the stable version, but both commercially and via the open source version.
CVEs are not just for serious issues, they are for vulnerabilities. All vulnerabilities. It is a number that allows you to reference an vulnerability, nothing more, nothing less.
Mentioning a CVE on the mailing list is the absolute least they should be doing.
‘workers can just be restarted anyway’ shows a deep misunderstanding of what a worker does. Any pending or active transactions that worker had now hangs, meaning that the service is still being denied. Trying to recover automatically from a DoS does not mean the DoS is not happening- it just means that the DoS is slower to get rolling, or intermittently seems to work mid-DoS.
There is an astounding number of lies/misrepresentations in your post, good lord.
I never said it isn’t an issue. Dos is the issue. It is a vulnerability.
No. CVE are not required. Like never. There is no legal requirements. The c in CVE stands for common btw… You know what is not common, Experimental features on non stable releases.
The stables are not affected. To quote from https://www.nginx.com/blog/updating-nginx-for-the-vulnerabilities-in-the-http-3-module/ about cve-2024-24989, “NGINX Open source mainline version 1.25.4. (The latest NGINX Open source stable version 1.24.0 is not affected.)” And about CVE-2024-24990, “NGINX Open source mainline version 1.25.4. (The latest NGINX Open source stable version 1.24.0 is not affected.)”
Yes and no. Remember the c in cve?
How is it a lie to say that they informed people through a mail list, when they did that? Remember you said I was lying? Also didn’t you say they wanted to keep it quiet to fix in secret, while they inform the public? Isn’t that a lie? (Also, you call it a cve in this point, well the dev didn’t think of it as one and he alerted the users. So they satisfied your “least” requirement for a cve while not thinking of it as a cve.)
My statement is once again not a lie. But let’s talk about your stuck transaction. Your transaction isn’t “stuck” if you use transactions in your database, but besides that you used an experimental feature on a non stable release on a publicly facing service and the “stuck” transaction is your issue? You are fucking without a condom, my friend. And That experimental feature might just crash randomly, due to memory leaks or what not, and your transaction is stuck too.
It’s an experimental feature. It doesn’t need a bugfix release because you’re not supposed to run it in production, and it’s just a DoS, not privilege escalation or something
Experimental features are explicitly defined as requiring CVEs. You are supposed to run them in production, that’s why they’re available as expiermental features and not on a development branch somewhere. You’re just supposed to run them carefully, and examine what they’re doing, so they can move out of experiment into mainline.
And that requires knowledge about any vulnerabilities, hence why it’s required to assigned CVEs to experimental features.
And I’m not sure why you think a DoS isn’t a vulnerability, that’s literally one of the most classic CVEs there are. A DoS is much, much more severe than a DDoS.
If you do examine what it’s doing you will catch this as soon as an attacker exploits it, and can disable it. Also, you should maybe not run the entire production with experimental features enabled. In a stable feature this would absolutely be a CVE, but this is marked experimental because it might not work right or even crash, like here
Correct, I agree you run it with an eye on it (which you should probably do anyway) instead of firing and forgetting (which, to nginx’s credit, is typically stable enough you can do that just fine).
That said, nginx treats experimental as something you explicitly run in production- when they announced they added it into experimental they actually specifically say to run it in prod in an A/B setup.
Nah, c suite was pretty clearly in the right here. Dude left because he was pissed that a vulnerability got assigned a CVE instead of just… Not informing anyone so they could quietly fix it.
Have you looked into the CVE? Apparently it is a non issue. You could use it to dos a service that have an experimental feature enabled, which is disabled by default, on a non stable Version. I understand the dev. CVE should be for serious issues. And they alerted their users over an email list
It can be used for dos, as it is crashing workers, but they will be restarted anyway.
There is an astounding number of lies in your post, good lord.
There is an astounding number of lies/misrepresentations in your post, good lord.
Where were my lies? I mean I showed you yours.
It’s an experimental feature. It doesn’t need a bugfix release because you’re not supposed to run it in production, and it’s just a DoS, not privilege escalation or something
Experimental features are explicitly defined as requiring CVEs. You are supposed to run them in production, that’s why they’re available as expiermental features and not on a development branch somewhere. You’re just supposed to run them carefully, and examine what they’re doing, so they can move out of experiment into mainline.
And that requires knowledge about any vulnerabilities, hence why it’s required to assigned CVEs to experimental features.
And I’m not sure why you think a DoS isn’t a vulnerability, that’s literally one of the most classic CVEs there are. A DoS is much, much more severe than a DDoS.
If you do examine what it’s doing you will catch this as soon as an attacker exploits it, and can disable it. Also, you should maybe not run the entire production with experimental features enabled. In a stable feature this would absolutely be a CVE, but this is marked experimental because it might not work right or even crash, like here
Correct, I agree you run it with an eye on it (which you should probably do anyway) instead of firing and forgetting (which, to nginx’s credit, is typically stable enough you can do that just fine).
That said, nginx treats experimental as something you explicitly run in production- when they announced they added it into experimental they actually specifically say to run it in prod in an A/B setup.
https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/
That means if you’re large enough that A can pick up the slack if B shits the bed. The only impact would be that you have to use HTTP2