7 ms·

> When a corporate tries to seize control of a open source project Yeah, they wanted to have some CVEs for a bunch of bugs in experimental code, the author of

> When a corporate tries to seize control of a open source project Yeah, they wanted to have some CVEs for a bunch of bugs in experimental code, the author of the fork didn't.

dns_snek 3y ago
What a weird hill to die on. Perhaps someone can illuminate the situation better, but I'm not keen to trust a project that seems to take CVE assignment against their software personally.
- codetrotter 3y ago
  Was the code in question included in stable releases? If not, I might agree that assigning CVEs are not helpful. But if the code was included in one or more stable release then I think it should probably have CVEs assigned. Depending on how serious or real the problems were.
  - ktosobcy 3y ago
    AFAIR it was im stable release BUTin a test code thats's behind a flag (disabled by default) so... it's a bit "shrodinger"
  - px43 3y ago
    I have personally reported bugs in the past that got closed as WONTFIX because they required some obscure configuration that the developer didn't believe would exist in the real world, but the way I found them was by breaking into actual real world servers owned by a client that I couldn't talk about due to an NDA. This happens a lot, and getting blown off constantly is a big reason why a lot of researchers just don't report bugs they find. I don't know much about these nginx bugs, but it seems like they were found in real live production systems, not by researchers trying to bump their CVE credits. Also it seems like quite a few people in the world are using nginx for HTTP/3 and quic, so trying to say "it doesn't count because it's not on by default" seems like a bit of a stretch. https://trac.nginx.org/nginx/ticket/2585 https://trac.nginx.org/nginx/ticket/2585 https://trac.nginx.org/nginx/ticket/2586 https://trac.nginx.org/nginx/ticket/2586
    - kuschku 3y ago
      These bugs only occurred if you compiled nginx yourself with custom flags during build. Should you be able to file CVEs against code posted in GitHub comments? StackOverflow Answers? Experimental branches on a maintainer's personal fork of the project?
      - jeltz 3y ago
        No, but code behind compile flags in a stable release seems like something we should file CVEs against.
      - dns_snek 3y ago
        The vulnerability also affected official version of Nginx Plus R30, released in August last year[1] and its release notes strongly suggest that the feature is no longer experimental. The steps required to use HTTP/3 in the open source version are also outlined in the official documentation, and you can find numerous guides for using Nginx with HTTP/3, demonstrating that the feature has reached some level of public adoption. This is in no way comparable to random snippets of code you find online, or in some experimental branch of a code repository that's not intended for public consumption. Filing a CVE for software that early adopters are likely to be using in production is completely justified, I'd certainly want to know about it. [1] https://www.nginx.com/blog/nginx-plus-r30-released/ https://www.nginx.com/blog/nginx-plus-r30-released/ > Native support for QUIC+HTTP/3 – NGINX Plus now has official support for HTTP/3. [...] > The QUIC+HTTP/3 support in NGINX Plus R30 is available as a single binary – unlike the experimental HTTP/3 support introduced in NGINX Plus R29, which had a separate binary for nginx quic. [...] > Full HTTP/3 support is added. NGINX 1.25.0 mainline version introduced support for HTTP/3, and this support has been merged into NGINX Plus R30. The NGINX Plus R30 implementation has the following changes when compared to the experimental packages delivered in NGINX Plus R29 [...]
        kuschku 3y ago
        And this is the cause of the conflict. Nginx, the open source project, was safe. No CVE should be assigned to it. NGINX PLUS, a separate and independent corporate product, was vulnerable. A CVE should be assigned specifically to it. The issue is that the maintainers of the open source nginx project were paid by the company behind NGINX PLUS, and the company demanded the CVE be assigned to the open source part.
  - jasode 3y ago
    >Was the code in question included in stable releases? If not, I might agree that assigning CVEs are not helpful. F5 employee says code the was marked as "experimental" but the issue is that customers were running it in production: https://news.ycombinator.com/item?id=39378523 https://news.ycombinator.com/item?id=39378523 https://news.ycombinator.com/item?id=39379984 https://news.ycombinator.com/item?id=39379984 It's worth going through that entire thread and Ctrl+F search userid "MZMegaZone" to get F5's rationale for assigning a CVE. Why are some customers running experimental code in production?!? I can only assume they do it to solve a problem and take early advantage of a new feature that doesn't exist in the stable release.
    - kuschku 3y ago
      Apparently F5 shipped it in production in their proprietary version, while it was not compiled into the free version. So technically the CVE should be filed against NGINX Plus, not nginx ;)
  - jeltz 3y ago
    It was included in stable releases but behind a compile time feature flag. Personally I think it was a very weird hill to die on. Weird to take CVEs so personally.
- deleted 3y ago
  [deleted]
- Smeevy 3y ago
  I obviously don't have any inside information on this, but I would presume that this isn't the first disagreement between the two parties. I, just as lots of others, have had to terminate business relationships over "last straw" types of infractions and misbehavior. I've never regretted doing so, but cutting ties after trying to make a situation work is not something I've ever been eager to do. I'm glad that I've never had to make that decision with something as well known as nginx.

> When a corporate tries to seize control of a open source project Yeah, they wanted to have some CVEs for a bunch of bugs in experimental code, the author of the fork didn't.

dns_snek 3y ago

What a weird hill to die on. Perhaps someone can illuminate the situation better, but I'm not keen to trust a project that seems to take CVE assignment against their software personally.

codetrotter 3y ago
Was the code in question included in stable releases? If not, I might agree that assigning CVEs are not helpful. But if the code was included in one or more stable release then I think it should probably have CVEs assigned. Depending on how serious or real the problems were.
- ktosobcy 3y ago
  AFAIR it was im stable release BUTin a test code thats's behind a flag (disabled by default) so... it's a bit "shrodinger"
- px43 3y ago
  I have personally reported bugs in the past that got closed as WONTFIX because they required some obscure configuration that the developer didn't believe would exist in the real world, but the way I found them was by breaking into actual real world servers owned by a client that I couldn't talk about due to an NDA. This happens a lot, and getting blown off constantly is a big reason why a lot of researchers just don't report bugs they find. I don't know much about these nginx bugs, but it seems like they were found in real live production systems, not by researchers trying to bump their CVE credits. Also it seems like quite a few people in the world are using nginx for HTTP/3 and quic, so trying to say "it doesn't count because it's not on by default" seems like a bit of a stretch. https://trac.nginx.org/nginx/ticket/2585 https://trac.nginx.org/nginx/ticket/2585 https://trac.nginx.org/nginx/ticket/2586 https://trac.nginx.org/nginx/ticket/2586
  - kuschku 3y ago
    These bugs only occurred if you compiled nginx yourself with custom flags during build. Should you be able to file CVEs against code posted in GitHub comments? StackOverflow Answers? Experimental branches on a maintainer's personal fork of the project?
    - jeltz 3y ago
      No, but code behind compile flags in a stable release seems like something we should file CVEs against.
    - dns_snek 3y ago
      The vulnerability also affected official version of Nginx Plus R30, released in August last year[1] and its release notes strongly suggest that the feature is no longer experimental. The steps required to use HTTP/3 in the open source version are also outlined in the official documentation, and you can find numerous guides for using Nginx with HTTP/3, demonstrating that the feature has reached some level of public adoption. This is in no way comparable to random snippets of code you find online, or in some experimental branch of a code repository that's not intended for public consumption. Filing a CVE for software that early adopters are likely to be using in production is completely justified, I'd certainly want to know about it. [1] https://www.nginx.com/blog/nginx-plus-r30-released/ https://www.nginx.com/blog/nginx-plus-r30-released/ > Native support for QUIC+HTTP/3 – NGINX Plus now has official support for HTTP/3. [...] > The QUIC+HTTP/3 support in NGINX Plus R30 is available as a single binary – unlike the experimental HTTP/3 support introduced in NGINX Plus R29, which had a separate binary for nginx quic. [...] > Full HTTP/3 support is added. NGINX 1.25.0 mainline version introduced support for HTTP/3, and this support has been merged into NGINX Plus R30. The NGINX Plus R30 implementation has the following changes when compared to the experimental packages delivered in NGINX Plus R29 [...]
      - kuschku 3y ago
        And this is the cause of the conflict. Nginx, the open source project, was safe. No CVE should be assigned to it. NGINX PLUS, a separate and independent corporate product, was vulnerable. A CVE should be assigned specifically to it. The issue is that the maintainers of the open source nginx project were paid by the company behind NGINX PLUS, and the company demanded the CVE be assigned to the open source part.
- jasode 3y ago
  >Was the code in question included in stable releases? If not, I might agree that assigning CVEs are not helpful. F5 employee says code the was marked as "experimental" but the issue is that customers were running it in production: https://news.ycombinator.com/item?id=39378523 https://news.ycombinator.com/item?id=39378523 https://news.ycombinator.com/item?id=39379984 https://news.ycombinator.com/item?id=39379984 It's worth going through that entire thread and Ctrl+F search userid "MZMegaZone" to get F5's rationale for assigning a CVE. Why are some customers running experimental code in production?!? I can only assume they do it to solve a problem and take early advantage of a new feature that doesn't exist in the stable release.
  - kuschku 3y ago
    Apparently F5 shipped it in production in their proprietary version, while it was not compiled into the free version. So technically the CVE should be filed against NGINX Plus, not nginx ;)
- jeltz 3y ago
  It was included in stable releases but behind a compile time feature flag. Personally I think it was a very weird hill to die on. Weird to take CVEs so personally.
deleted 3y ago
[deleted]
Smeevy 3y ago
I obviously don't have any inside information on this, but I would presume that this isn't the first disagreement between the two parties. I, just as lots of others, have had to terminate business relationships over "last straw" types of infractions and misbehavior. I've never regretted doing so, but cutting ties after trying to make a situation work is not something I've ever been eager to do. I'm glad that I've never had to make that decision with something as well known as nginx.