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.
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.
Note: The HTTP/3 QUIC module is not enabled by default and is considered experimental
Do note that despite not being enabled by default, it is enabled in the official binary packages.
There’s a funny amount of layers to this thing but as far as I’m concerned, if it’s a feature you ship in the default binary packages on your site, that is definitively enough for a CVE even if it’s disabled by default.
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.
As a developer myself (though not on the level of these guys): sorry, but just, no.
The key point is this:
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.
deleted by creator
Do note that despite not being enabled by default, it is enabled in the official binary packages.
There’s a funny amount of layers to this thing but as far as I’m concerned, if it’s a feature you ship in the default binary packages on your site, that is definitively enough for a CVE even if it’s disabled by default.
Yeah I can definitely see why the devs decided to just fix it on the next patch. Reporting a CVE for this feels very unnecessary.
Thank you for digging this out. Turns out it’s even worse than what I gleaned from my surface-level take.
Thanks for this. I get now why the devs are pissed.
You’re not missing anything, dude just threw a hissy fit because he’s not the king of his fiefdom anymore.