There's obviously more to this story, as there is a corresponding blog post from F5 posted today as well: https://www.nginx.com/blog/nginx-continued-commitment-to-securing-users-in-action/ So what...
There's obviously more to this story, as there is a corresponding blog post from F5 posted today as well:
As often with posts like these there is also a hackernews post. Mostly speculation there as well but it seems like they didn't agree with CVE classifications for experimental features.
As often with posts like these there is also a hackernews post. Mostly speculation there as well but it seems like they didn't agree with CVE classifications for experimental features.
Dev's motivation in more detail: https://mailman.nginx.org/pipermail/nginx-devel/2024-February/YIFSHIYSKDFBYZ2QRA3WF6SRPGIBDBKI.html I'm not familiar with like, the industry norms on CVEs but......
The most recent "security advisory" was released despite the fact
that the particular bug in the experimental HTTP/3 code is
expected to be fixed as a normal bug as per the existing security
policy, and all the developers, including me, agree on this.
And, while the particular action isn't exactly very bad, the
approach in general is quite problematic.
There was no public discussion. The only discussion I'm aware of
happened on the security-alert@ list, and the consensus was that
the bug should be fixed as a normal bug. Still, I was reached
several days ago with the information that some unnamed management
requested an advisory and security release anyway, regardless of
the policy and developers position.
I'm not familiar with like, the industry norms on CVEs but... as F5 sells the product they may be liable if they're not excessively cautious here. Would anybody care to comment? I'm curious if the dev has a point or is overreacting.
I can't comment on this specifically but I've always experienced friction between developers and management when it comes to cybersecurity. It feels like each see half of the picture and get...
I can't comment on this specifically but I've always experienced friction between developers and management when it comes to cybersecurity. It feels like each see half of the picture and get frustrated with the other side.
A common example is when some library has a critical vulnerability posted on NVD and the CISO sounds the alarm for an urgent fix. Then the dev team explains that the product only uses a small function of that library to do something relatively benign like render a chart. The CISO cannot overcome the sheer horror of having one critical CVSS score on the vulnerability scan and the dev team cannot fathom making an unnecessary fix.
Ultimately, as a function that is tangentially involved during these disputes, I feel like this comes down to a better understanding of security and risk management. A CVSS score is only part of the picture and is almost completely independent of context. In my work, I try to ensure that a CVSS score is only considered alongside the severity of its exploitation. In this case, that probably means siding with this developer.
I wonder if this will open the door to commercial nginx features being cloned and added to the free nginx. I’m thinking specifically of the adaptive bitrate stuff for VOD.
I wonder if this will open the door to commercial nginx features being cloned and added to the free nginx.
I’m thinking specifically of the adaptive bitrate stuff for VOD.
There's obviously more to this story, as there is a corresponding blog post from F5 posted today as well:
https://www.nginx.com/blog/nginx-continued-commitment-to-securing-users-in-action/
So what exactly is going on here? Anybody been closely following what's been happening and could sum up?
As often with posts like these there is also a hackernews post. Mostly speculation there as well but it seems like they didn't agree with CVE classifications for experimental features.
Dev's motivation in more detail: https://mailman.nginx.org/pipermail/nginx-devel/2024-February/YIFSHIYSKDFBYZ2QRA3WF6SRPGIBDBKI.html
I'm not familiar with like, the industry norms on CVEs but... as F5 sells the product they may be liable if they're not excessively cautious here. Would anybody care to comment? I'm curious if the dev has a point or is overreacting.
I can't comment on this specifically but I've always experienced friction between developers and management when it comes to cybersecurity. It feels like each see half of the picture and get frustrated with the other side.
A common example is when some library has a critical vulnerability posted on NVD and the CISO sounds the alarm for an urgent fix. Then the dev team explains that the product only uses a small function of that library to do something relatively benign like render a chart. The CISO cannot overcome the sheer horror of having one critical CVSS score on the vulnerability scan and the dev team cannot fathom making an unnecessary fix.
Ultimately, as a function that is tangentially involved during these disputes, I feel like this comes down to a better understanding of security and risk management. A CVSS score is only part of the picture and is almost completely independent of context. In my work, I try to ensure that a CVSS score is only considered alongside the severity of its exploitation. In this case, that probably means siding with this developer.
I wonder if this will open the door to commercial nginx features being cloned and added to the free nginx.
I’m thinking specifically of the adaptive bitrate stuff for VOD.
I don't see why not. Provided its a new implementation of said feature.