Hacker News new | ask | show | jobs
by Twirrim 856 days ago
I'm inclined to agree with your decision to create and publish CVEs for these, honestly. You were shipping code with a now-known vulnerability in it, even if it wasn't compiled in by default.
1 comments

if it's not compiled in by default, then you aren't shipping the code! Somebody is downloading it and compiling it themselves!
Incorrect. Features available to users still require a minimum, standard level of support. This is like the deceptive misnomer of staging and test environments provided to internal users used no differently than production in all but name.
Nobody does it like that though, what vendor declares unsupported is unsupported.
That .. is the definition of shipping the code, the code is being shipped to the people downloading and compiling it for themselves
If the feature is in the code that's downloaded, regardless of whether or not the build process enables it by default, the code is definitely being shipped.
BRB, filing CVE's against literally any project with example code in their documentation...
That's actually supported by the CVE program rules. Have at it if you find examples with security vulns.
I've actually seen CVEs like that before, I agree that's bonkers but I have seen it...
Given how frequently people copy and paste example code… why is that surprising? Folks need to be informed. CVEs are a channel for that.
Pssst: People who copy+paste example code aren't checking CVEs
Yes. It's no different from any optional feature. Actual beta features should only be shipped in beta software .
You and I have very different notions of "shipped". It's open source code, it's being made publicly available. That's shipped, as I see it.
This is an insane standard and attempting to adhere to it would mean that the CVE database, which is already mostly full of useless, irrelevant garbage, is now just the bug tracker for _every single open source project in the world_.
This. CVE has become garbage because "security researchers" are incentivized to file anything and everything so they can put it on their resume.
Why is it insane? The CVE goal was to track vulnerabilities that customers could be exposed to. It is used…in public, released versions. Why wouldn’t it be tracked?
Because it's not actually part of the distribution unless you compile it yourself.

It is not released any sense of the word. It is not even a complete feature.

I am actually completely shocked this needs to be explained. Legitimate insanity.

It's in the published source code, as a usable feature, just flagged as experimental and not compiled by default. It's not like this is some random development branch. It's there, to be used en route to being stable. People will have downloaded a release tagged version of the source code, compiled that feature in and used it.

By what definition is that not shipped?

> I am actually completely shocked this needs to be explained. Legitimate insanity.

Right back at you.

You're all also missing the fact that the vuln is also in the NGINX+ commercial product, not just OSS. Which has a different release model.

Being the same code it'd be darn strange to have the CVE for one and not the other. We did ask ourselves that question and quickly concluded it made no sense.

Docs say its compiled into the Linux binaries by default:

http://nginx.org/en/docs/quic.html

"Also, since 1.25.0, the QUIC and HTTP/3 support is available in Linux binary packages."

I guess a vulnerability doesn’t count unless it’s default lol. Just don’t make it default and you never have any responsibility nor does those who use it or use a vendor version that has added it in their product.
You know that random thing you mucked around on Github X years ago then forgot about, and it's amongst 30 other random repos?

Should people file a CVE against that?