[MZMegaZone]

I think you'd have to ask Maxim. My take is he felt experimental features should not get CVEs, which isn't how the program works. But that's just my take - I'm the primary representative for F5 to the CVE program and on the F5 SIRT, we handle our vuln disclosures.

[Twirrim]

I'm inclined to agree with your decision to create and publish CVEs for these, honestly. You were shipping code with a now-known vulnerability in it, even if it wasn't compiled in by default.

[aaronbwebber]

if it's not compiled in by default, then you aren't shipping the code! Somebody is downloading it and compiling it themselves!

[anon-sre-srm]

Incorrect. Features available to users still require a minimum, standard level of support. This is like the deceptive misnomer of staging and test environments provided to internal users used no differently than production in all but name.

[GoblinSlayer]

Nobody does it like that though, what vendor declares unsupported is unsupported.

[mort96]

That .. is the definition of shipping the code, the code is being shipped to the people downloading and compiling it for themselves

[kelnos]

If the feature is in the code that's downloaded, regardless of whether or not the build process enables it by default, the code is definitely being shipped.

[ramses0]

BRB, filing CVE's against literally any project with example code in their documentation...

[MZMegaZone]

That's actually supported by the CVE program rules. Have at it if you find examples with security vulns.

[spicykraken]

I've actually seen CVEs like that before, I agree that's bonkers but I have seen it...

[numbsafari]

Given how frequently people copy and paste example code… why is that surprising? Folks need to be informed. CVEs are a channel for that.

[anon-sre-srm]

Yes. It's no different from any optional feature. Actual beta features should only be shipped in beta software .

[Twirrim]

You and I have very different notions of "shipped". It's open source code, it's being made publicly available. That's shipped, as I see it.

[aaronbwebber]

This is an insane standard and attempting to adhere to it would mean that the CVE database, which is already mostly full of useless, irrelevant garbage, is now just the bug tracker for _every single open source project in the world_.

[TedDoesntTalk]

This. CVE has become garbage because "security researchers" are incentivized to file anything and everything so they can put it on their resume.

[xcrunner529]

Why is it insane? The CVE goal was to track vulnerabilities that customers could be exposed to. It is used…in public, released versions. Why wouldn’t it be tracked?

[whoknowsidont]

Because it's not actually part of the distribution unless you compile it yourself.

It is not released any sense of the word. It is not even a complete feature.

I am actually completely shocked this needs to be explained. Legitimate insanity.

[Reelix]

You know that random thing you mucked around on Github X years ago then forgot about, and it's amongst 30 other random repos?

Should people file a CVE against that?

[droopyEyelids]

(not explicitly asking you, MZMegaZone) Does anyone understand why a disagreement about this would be worth the extra work in forking the project?

I'm not very familiar with the implications, so it seems like a relatively fine hair to split- as though the trouble of dealing with these as CSV would be less than the extra work of forking.

[kelnos]

It probably wasn't. There's likely something else going on. Either Dounin had already decided to fork for other reasons, and the timing was coincidental, or there were a lot of reasons building up, and this was the final straw.

Or he's just a very strange man, and for some reason this pair of CVEs was oddly that important to him.