4 ms·

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?

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.

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.