[MZMegaZone]

We know a number of customers/users have the code in production, experimental or not. And that was part of decision process. The security advisories we published do state the feature is experimental.

When in doubt, err on the side of doing the right thing for the users. I find that's the best approach. I don't consider CVE a bad thing - it shouldn't be treated like a scarlet letter to be avoided. It is a unique identifier that makes it easy to talk about a specific issue and get the word out to customers/users so they can protect themselves. And that's a good thing.

The question I ask is "Why not assign a CVE?" You have to have a solid reason why not to do it, because of default is to assign and disclose.

I don't think having the CVEs should reflect poorly on NGINX or Maxim. I'm sorry he feels the way he does, but I hold no ill will toward him and wish him success, seriously.

[gwd]

FWIW, in my project the main reason we don't issue security advisories for "unsupported" code ("experimenal" or "tech preview") is to reduce the burden for our downstreams: many of our immediate downstreams are expected by their users to apply every single security patch, regardless of whether they even use the affected functionality. For cloud providers doing this across a massive fleet, this is a fair amount of work that's worth avoiding if we can.

On the other hand, since the definition of "supported" is specifically designed to help downstreams, if it were known that some bit of code was widely used in production, we'd be open to declaring it "security supported", regardless of whether we thought it was "finished" or not.

[gav]

Recently I had to support a client who had a "no CVEs in a production deploy, ever" policy.

The stack included Linux, Java, Chromium, and MySQL. It took multiple person-years of playing whack-a-mole with dependencies to get it into production because we'd have to have conversations like:

  Client: there's a CVE in the this module 
  Us: that's not exploitable because it's behind a configuration option that we haven't enabled
  Client: somebody could turn it on
  Us: even if they somehow did and nobody noticed, they would have to stand up a server inside your VPC and connect to that
  Client: well what if they did that?
  Us: then they'd already have root and you are hosed 
  Client: but the CVE
  Us: 

So I definitely appreciate any vendor that tries to minimize CVEs.

[Reelix]

In their defense, if the latest version of a module has a CVE, then it's either a 0-day, or an unsupported module.

In either case, you should probably do something about it.

[MZMegaZone]

That's just a braindead policy.

Really, really dumb. Not at all good security, just checking boxes.

[gwd]

I mean, yeah, but if that's the way big bureaucratic organizations get sometimes. Bigger means more likely to have a brain-dead policy like this, but also more money... so, do you give up the money, or do you accommodate their policy while trying to minimize the cost?

[MZMegaZone]

Oh, I'll cash their check. I'll tell them, in professional terms, why they should change their policy, but I'll still cash the check.

[arp242]

> The question I ask is "Why not assign a CVE?"

There's tons of reasons why you wouldn't, but the core reason for this fork probably isn't really about the CVEs as such. It's either the final straw in a long line of disagreements, or the entire thing was handled was so badly that he no longer wants to work with these people. Or most likely: a combination of both.

I once quit after a small disagreement because the owner cut off my explanation on why I built something the way I did with "I don't care, just do what I say". This was after he ignored the discussion on how to design it, and ignored requests for feedback when I was building it. And look, I don't mind to re-doing it even if I don't agree it's better better, but I did put quite a lot of thought and effort in to it and thought it worked very well. If you don't even want to spend 3 minutes listening to the reasons on why it's like that then kindly go fuck yourself.

It's not the disagreement as such that matters, it's the lack of basic respect.

[braiamp]

What does policy says about reporting security issues with experimental/not-enabled-by-default/unstable code?

[arter4]

As an outsider to this whole thing (having discovered this issue in this thread, like pretty much anyone), the CVE rules simply say that you cannot assign a CVE to vulnerabilities in a product that is not publicly available or licensable. Experimental, but publicly available features are still in scope.

This makes sense IMHO: experimental features may be buggy, but they may work in your limited use case. So you may be inclined to use them...except you don't know they expose you in a critical way.

[MZMegaZone]

Exactly - this very question came up. And pretty much everyone looked at me as I'm the one who sits on every CVE.org working group (BTW, the CVE rules are currently being revised and in comment period for said revision) and I explained exactly that - just because it is experimental doesn't mean it is out of scope.

Also, something that keeps getting lost here, the CVE is NOT just against NGINX OSS, but also NGINX+, the commercial product. And the packaging, release, and messaging on that is a bit different. That had to be part of the decision process too. Since it is the same code the CVE applies to both. This was not a rash decision or one made without a lot of discussion and consideration of multiple factors.

But one of our guiding principles that we literally ask ourselves during these things is "What is the right thing to do?" Meaning, what is the right thing for the users, first and foremost. That's part of the job, IMHO. Some vendors never disclose anything, but that's not how we operate. I've written a few articles on F5's DevCentral site about this - "Why We CVE" and "CVE: Who, What, Where, and When" are particularly on topic for this, I think.

[GoblinSlayer]

All features have limited use case, but experimental features may be buggy in all use cases, which is exactly what happened here. CVE is uninformative there, defects are implied, might as well create a CVE for every commit "something happened, don't forget to repedloy".

[JackSlateur]

  The question I ask is "Why not assign a CVE?"

Exactly: why not ? Glory to the Linux Kernel which is on its way to assign CVE for everything :)

[MZMegaZone]

That's a whole different discussion - which isn't as dramatic as it is being made out to be.

Other hats I wear (outside of my day job) include being on every (literally, every) CVE.org Working Group and being the newly elected CNA Liaison to the CVE Board. This has been a subject of discussion and things are a bit overblown right now, IMHO. Some of the initial communications were perhaps not as clear as they could have been. But it isn't going to be every kernel bug being a CVE - not every bug is a vuln.

I'm also one of the co-chairs for the upcoming VulnCon in Raleigh, NC. Just a plug. ;-)

[mike_d]

Answering your original question to posted to me a bit down thread with this important context. The answer to "why not issue a CVE?" is the same reason that you don't call every random car burglary or graffiti an act of terrorism.

While I agree the whole Linux CVE thing is a bit overblown, but as an outside observer the new policy [1] does not read like they are super happy with CVE in general.

Too bad the CFP is closed for VulnCon, it might be fun to do a "Assume everything is wrong and you can't do anything the way you do it now - how do you build CVE 2.0" (also that title is too long).

1. https://lwn.net/ml/linux-kernel/2024021314-unwelcome-shrill-...

[MZMegaZone]

We got around 150 submissions for 30ish panel slots over three days, so we're good there. Schedule should be out soon.

The CVE program has grown and changed a lot the past few years, and the rules are undergoing a major revision right now (comment period currently) taking in a lot of the feedback. And the rate of CNAs joining has been picking up rapidly as global interest in the program has increased.

No one thinks it is perfect, but that's why a lot of us are active in the working groups and trying to keep moving things forward.

[Reelix]

EVERYTHING.

Found a missing comma in the documentation of a function? Yup - That's a CVE ;p