209
submitted 9 months ago by poVoq@slrpnk.net to c/opensource@lemmy.ml
you are viewing a single comment's thread
view the rest of the comments
[-] BaumGeist@lemmy.ml 23 points 9 months ago

Context:

TLDR: The devs don't like bugs in released software being assigned CVEs, which requires a special security update instead of a standard bugfix included in the regular update cycle.

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

And nginx's announcement about these CVEs

Historically, we did not issue CVEs for experimental features and instead would patch the relevant code and release it as part of a standard release. For commercial customers of NGINX Plus, the previous two versions would be patched and released to customers. We felt that not issuing a similar patch for NGINX Open Source would be a disservice to our community. Additionally, fixing the issue in the open source branch would have exposed users to the vulnerability without providing a binary.

Our decision to release a patch for both NGINX Open Source and NGINX Plus is rooted in doing what is right – to deliver highly secure software for our customers and community. Furthermore, we’re making a commitment to document and release a clear policy for how future security vulnerabilities will be addressed in a timely and transparent manner.

[-] cybersandwich@lemmy.world 15 points 9 months ago

I...agree with the "company" I think. This sounds like dev sour grapes but what the company was asking them to do seems better from the customer pov and for cyber security I'm general.

Maybe I'm missing something.

[-] fernandofig@reddthat.com 27 points 9 months ago

This sounds like dev sour grapes but what the company was asking them to do seems better from the customer pov and for cyber security I'm general.

As a developer myself (though not on the level of these guys): sorry, but just, no.

The key point is this:

[...] we did not issue CVEs for experimental features and instead would patch the relevant code and release it as part of a standard release.

Emphasis mine. In software, features marked as "experimental" usually are not meant to be used in a production environment, and if they are, it's in a "do it at your own risk" understanding. Software features in an experimental state are expected to be less tested and have bugs - it's essentially a "beta" feature. It has a security bug? Though - you weren't supposed to be using it in a security-sensitive environment in the first place, it sounds perfectly reasonable to me that it should be addressed in a normal release as opposed to an out-of-band one.

We can argue if forking the project is or isn't extreme, but the devs absolutely have good reason to be pissed. This is typical management making decisions without understanding technical nuances and - from what is being told by the devs - not talking it through before doing it.

load more comments (6 replies)
load more comments (6 replies)
this post was submitted on 15 Feb 2024
209 points (97.3% liked)

Open Source

31358 readers
71 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS