6 ms·

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

by 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.
    - dns_snek 3y ago
      Nginx, the open source project, wasn't "safe". It was merged, released, came with documentation, and it had public use. I think that's all that matters. How else do you propose that users are informed about vulnerabilities in their installation? That's what CVEs are for.
      - kuschku 3y ago
        Whether you develop new features on main gated by compile flags or on separate branches shouldn't have an effect on CVE assigments. I'm pretty sure that setting arbitrary compile flags is enough to cause vulnerabilities in most software. I personally ran nginx without this feature enabled because it was explicitly marked as experimental and potentially unsafe.
juped 3y ago
There is no valid reason for "won't fix" to be a bug status, even if you aren't going to fix the bug. There's a status for that: "open".
- codetrotter 3y ago
  Open is for tickets that are intended to be fixed. Having nine gazillion open tickets is helpful for no one. Devs will have to wade through open tickets that are not meant to be worked on time over again. Tickets that should be worked on will be lost in the sea of irrelevant tickets. People affected by the issue will see the open ticket and think it means that it’s going to be fixed.
  - juped 3y ago
    Yes, we've all had or heard horror stories of managers like you who flip out over open and closed ticket metrics. That doesn't make it good practice.
- HankB99 3y ago
  That ("open") seems reasonable for a bug in the current release or a previous release that is still in wide use. Is there ever a situation where a bug exists so far back in the history of the project that it doesn't make sense to fix? I'm asking this as an honest question and not a challenge. I can expect that some users still use what I'd consider to be legacy S/W but I wonder how far that goes back. If the developer(s) designate a version as EOL does it make sense to keep the bug open? And OTOH, it conveys information if the developer marks a bug as "won't fix" rather than leaving the expectation that it might be addressed, someday.
  - juped 3y ago
    If the bug only exists in old versions that sounds like a great case for marking it "fixed"! (Or possibly a cousin like "moot because this subsystem was deleted".)

by px43 3y ago

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.
  - dns_snek 3y ago
    Nginx, the open source project, wasn't "safe". It was merged, released, came with documentation, and it had public use. I think that's all that matters. How else do you propose that users are informed about vulnerabilities in their installation? That's what CVEs are for.
    - kuschku 3y ago
      Whether you develop new features on main gated by compile flags or on separate branches shouldn't have an effect on CVE assigments. I'm pretty sure that setting arbitrary compile flags is enough to cause vulnerabilities in most software. I personally ran nginx without this feature enabled because it was explicitly marked as experimental and potentially unsafe.

juped 3y ago

There is no valid reason for "won't fix" to be a bug status, even if you aren't going to fix the bug. There's a status for that: "open".

codetrotter 3y ago
Open is for tickets that are intended to be fixed. Having nine gazillion open tickets is helpful for no one. Devs will have to wade through open tickets that are not meant to be worked on time over again. Tickets that should be worked on will be lost in the sea of irrelevant tickets. People affected by the issue will see the open ticket and think it means that it’s going to be fixed.
- juped 3y ago
  Yes, we've all had or heard horror stories of managers like you who flip out over open and closed ticket metrics. That doesn't make it good practice.
HankB99 3y ago
That ("open") seems reasonable for a bug in the current release or a previous release that is still in wide use. Is there ever a situation where a bug exists so far back in the history of the project that it doesn't make sense to fix? I'm asking this as an honest question and not a challenge. I can expect that some users still use what I'd consider to be legacy S/W but I wonder how far that goes back. If the developer(s) designate a version as EOL does it make sense to keep the bug open? And OTOH, it conveys information if the developer marks a bug as "won't fix" rather than leaving the expectation that it might be addressed, someday.
- juped 3y ago
  If the bug only exists in old versions that sounds like a great case for marking it "fixed"! (Or possibly a cousin like "moot because this subsystem was deleted".)