8 ms·

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

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_.

TedDoesntTalk 3y ago
This. CVE has become garbage because "security researchers" are incentivized to file anything and everything so they can put it on their resume.
xcrunner529 3y ago
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?
- whoknowsidont 3y ago
  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.
  - Twirrim 3y ago
    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.
    - whoknowsidont 3y ago
      >just flagged as experimental and not compiled by default Are UML diagrams considered in scope too?
      - arter4 3y ago
        UML diagrams are not code. You cannot file a CVE for something that is not an actual (software or hardware) implementation.
    - YetAnotherNick 3y ago
      > to be used en route to being stable Where did you get this info? It might be the feature is actively being worked on and the DoS is a known issue which would be fixed before merge. Lot of projects have contrib folder for random scripts and other things which wouldn't get merged before some review but users are free to run the script if they want to. Experimental compile time build flags are experimental by definition.
    - bnolsen 3y ago
      I've had an optional experimental feature marked with a CVE. It's not a big deal as it just lets folks know that they should upgrade if they are using that experimental feature in the affected versions.
  - xcrunner529 3y ago
    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.
    - whoknowsidont 3y ago
      >I guess a vulnerability doesn’t count unless it’s default lol. It's still being tested. It's not complete. It's not released. It's not in the distribution. The amount of people that have this feature in the binary AND enabled is less than the amount of people that agree that this should be a CVE. CVE's are not for tracking bugs in unfinished features.
      - xcrunner529 3y ago
        It IS in the code that anyone can compile to use or integrate in projects as is the OSS way. Splitting hairs because it’s not in the default binary is absurd. Guess all the extra FFMPEG compilation flags and such shouldn’t count either.
  - MZMegaZone 3y ago
    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.
    - statquontrarian 3y ago
      "made no sense" from a narrow, CVE announcement perspective, but Maxim disagrees from another perspective: > [F5] decided to interfere with security policy nginx > uses for years, ignoring both the policy and developers’ position. > > That’s quite understandable: they own the project, and can do > anything with it, including doing marketing-motivated actions, > ignoring developers position and community. Still, this > contradicts our agreement. And, more importantly, I no longer able > to control which changes are made in nginx within F5, and no longer > see nginx as a free and open source project developed and > maintained for the public good. I'm not sure what "contradicts our agreement" means but the simple interpretation is that he feels that F5 have become too dictatorial to the open source project. The whole drama seems very short-sighted from F5's perspective. Maxim was working for you for free for years and you couldn't find some middle ground? I imagine there could have been some page on the free nginx project that listed CVEs that are in the enterprise product but that are not considered CVEs for the open source project given its stated policy of not creating CVEs for experimental features, or something like that. To nuke the main developer, cause this rift in the community, and create a fork seems like a great microcosm of the general tendency of security leads to wield uncompromising power. I get it. Security is important. But security isn't everything and these little fiefdoms that security leads build up are bureaucratic and annoying. I hope you understand that these uncompromising policies actually reduce security in the end because 10X developers like Maxim will start to tend to avoid the security team and, in the worst case, hide stuff from their security team. I've seen this play out over and over in large corporations. In that sense, the F5 security team is no different. But there should be a collaborative, two-way process between security and development. I'm sure security leads will say that they have that, but that's not what I find. Ultimately, if there's an escalation, executives will side with the security lead, so it is a de facto dictatorship even if security leads will tend to avoid the nuclear option. But when you take the nuclear option, as you did in this case, don't be surprised by the consequences.
  - kayfox 3y ago
    Docs say its compiled into the Linux binaries by default: http://nginx.org/en/docs/quic.html http://nginx.org/en/docs/quic.html "Also, since 1.25.0, the QUIC and HTTP/3 support is available in Linux binary packages."
- Reelix 3y ago
  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?

TedDoesntTalk 3y ago

This. CVE has become garbage because "security researchers" are incentivized to file anything and everything so they can put it on their resume.

xcrunner529 3y ago

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?

whoknowsidont 3y ago
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.
- Twirrim 3y ago
  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.
  - whoknowsidont 3y ago
    >just flagged as experimental and not compiled by default Are UML diagrams considered in scope too?
    - arter4 3y ago
      UML diagrams are not code. You cannot file a CVE for something that is not an actual (software or hardware) implementation.
  - YetAnotherNick 3y ago
    > to be used en route to being stable Where did you get this info? It might be the feature is actively being worked on and the DoS is a known issue which would be fixed before merge. Lot of projects have contrib folder for random scripts and other things which wouldn't get merged before some review but users are free to run the script if they want to. Experimental compile time build flags are experimental by definition.
  - bnolsen 3y ago
    I've had an optional experimental feature marked with a CVE. It's not a big deal as it just lets folks know that they should upgrade if they are using that experimental feature in the affected versions.
- xcrunner529 3y ago
  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.
  - whoknowsidont 3y ago
    >I guess a vulnerability doesn’t count unless it’s default lol. It's still being tested. It's not complete. It's not released. It's not in the distribution. The amount of people that have this feature in the binary AND enabled is less than the amount of people that agree that this should be a CVE. CVE's are not for tracking bugs in unfinished features.
    - xcrunner529 3y ago
      It IS in the code that anyone can compile to use or integrate in projects as is the OSS way. Splitting hairs because it’s not in the default binary is absurd. Guess all the extra FFMPEG compilation flags and such shouldn’t count either.
- MZMegaZone 3y ago
  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.
  - statquontrarian 3y ago
    "made no sense" from a narrow, CVE announcement perspective, but Maxim disagrees from another perspective: > [F5] decided to interfere with security policy nginx > uses for years, ignoring both the policy and developers’ position. > > That’s quite understandable: they own the project, and can do > anything with it, including doing marketing-motivated actions, > ignoring developers position and community. Still, this > contradicts our agreement. And, more importantly, I no longer able > to control which changes are made in nginx within F5, and no longer > see nginx as a free and open source project developed and > maintained for the public good. I'm not sure what "contradicts our agreement" means but the simple interpretation is that he feels that F5 have become too dictatorial to the open source project. The whole drama seems very short-sighted from F5's perspective. Maxim was working for you for free for years and you couldn't find some middle ground? I imagine there could have been some page on the free nginx project that listed CVEs that are in the enterprise product but that are not considered CVEs for the open source project given its stated policy of not creating CVEs for experimental features, or something like that. To nuke the main developer, cause this rift in the community, and create a fork seems like a great microcosm of the general tendency of security leads to wield uncompromising power. I get it. Security is important. But security isn't everything and these little fiefdoms that security leads build up are bureaucratic and annoying. I hope you understand that these uncompromising policies actually reduce security in the end because 10X developers like Maxim will start to tend to avoid the security team and, in the worst case, hide stuff from their security team. I've seen this play out over and over in large corporations. In that sense, the F5 security team is no different. But there should be a collaborative, two-way process between security and development. I'm sure security leads will say that they have that, but that's not what I find. Ultimately, if there's an escalation, executives will side with the security lead, so it is a de facto dictatorship even if security leads will tend to avoid the nuclear option. But when you take the nuclear option, as you did in this case, don't be surprised by the consequences.
- kayfox 3y ago
  Docs say its compiled into the Linux binaries by default: http://nginx.org/en/docs/quic.html http://nginx.org/en/docs/quic.html "Also, since 1.25.0, the QUIC and HTTP/3 support is available in Linux binary packages."
Reelix 3y ago
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?