@gregkh I'm excited to see this taking shape! It's going to be quite the fire-hose of identifiers, but I think that'll more accurately represent the number of fixes landing in stable trees and how important it is for end users to stay current on a stable kernel.
@joshbressers @gregkh I'd say the failure is in the (not so) recent gamification of CVE IDs, not necessarily in the fact that the process is becoming increasingly federated. I'm actually optimistic about this (we set up a CNA for glibc more recently) and security policies because it makes our participation in security conversations more deliberate and actually gives us communities a lot more control.
@B97 @joshbressers @gregkh So we have the situation where people want to consume normalized security data, since basically forever, speaking from experience as an analyst at iSIGHT partners and then iDefence and then Red Hat.
Organizations do not want to pay for this data. In the past they could get away with not having or using it, but modern security scanners and so on make it harder to hide flaws in the software you ship from your customers, especially if it uses Open Source (which everything does now).
The "solution" of moving the burden of normalized security data directly onto the Open Source projects by encouraging them to become CNAs is not possible or sustainable for many, indeed if this was so easy why are critical entities like curl and the Linux Kernel just now becoming CNA's (and often because they want to reduce the flow of bad CVEs...).
This is especially worrisome, as Greg KH points out that this type of activity might even be mandated by legislation in parts of the world.
Now ask yourself this:
Will requiring Open Source projects to take on additional work and liability, like being a CNA, encourage or discourage people from developing Open Source software and freely releasing it?
"I am not a supplier"
@B97 @joshbressers @gregkh citation for vulnerabilities being injected please. I’ve seen that claim but outside of a handful of cases (few enough that we covered them on the #osspodcast) there is no real evidence of this happening in a widespread manner.
@B97 @joshbressers @gregkh there’s a handful of events like https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/amp/ but if you’re saying there’s a lot, can you provide links to them? Thanks.
@buherator @gregkh That's a pretty reasonable conclusion, but that's not really why anyone is doing this
@bagder explains this better than I can in this blog post
https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/
It should be trivial for a project to update vulnerability details. Except it's not even hard, it's basically impossible
Will be interesting to see how the new process[1] plays together with "participation in stable is optional for mainline developers" and the "developers almost never declare specific changes as security fixes"[2] approach I assume still holds true for mainline.
I sounds like it could easily happen that someone fixes a security bug in mainline w/o telling anybody, so no CVE would be issued unless someone backports the change.
[1] https://lore.kernel.org/lkml/2024021314-unwelcome-shrill-690e@gregkh/
[2] http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/#security
Will also be interesting to see how many CVE will be issued it the end; it sounds like it will be a whole lot, which likely will have some interesting effects. 😬
@kernellogger @gregkh that's the way it sounds. You want CVEs? GREAT HERE'S TEN THOUSAND OF THEM!
@gregkh @joshbressers @kurtseifried @B97 i will note that the last sentence means noone should use autotools anymore.
That seems. Dubious.
@gregkh @joshbressers @kurtseifried @B97 because from 2012 to 2020 there was no maintainers and updates for autoconf. As such, it was not regularly producing updates.
@gregkh While I understand the reason for this, I think a lot of the very serious people will declare it some sort of success
The fact that all these open source projects are dedicating resources to becoming CNAs isn't a good thing. It's because this process is so comically broken, this was seen as the only option
Open source projects becoming CNAs is what failure looks like, we shouldn't pretend otherwise
@gregkh @joshbressers @kurtseifried @B97 i mean i do not disagree with you, but i think it goes against the standard you advocated for above :)
The vast majority of open source projects are one person
https://anchore.com/blog/open-source-is-bigger-than-you-imagine/
And honestly, even a small fraction of them tried to become CNAs it would crush the system. It’s a closed environment that relies on manual effort
This might be ok for a large project like the kernel, but certainly not for most projects
@joshbressers @gregkh I agree that open source projects becoming CNAs is largely a bad idea. Among other things, it creates a conflict of interest around CVE designations. CVEs are looked down upon, for better or worse, and as a result, there's a pressure to have fewer of them. When the project issues its own CVEs, it's a lot easier to just... *not* do it.
CVE data doesn't work if there's no independent process forcing CVEs to be declared.
@gregkh A very interesting read. I'm very curious how this will interact with the "a CVE is a todo item" crowd (for both good and ill).
@Conan_Kudo @joshbressers @gregkh I feel like you're mixing up Open Source and (bad) corporate behavior. I've seen a corp being CNA for their enterprise products and just not fixing for over six months the obvious security issues (like o+w files regularly executed by root
) we reported through the normal support process as a customer, not to mention a CVE.
@gregkh Yes, I was counting that on the "good" side of "good or ill".
@gregkh out of interest - how to you plan to document CVEs that require multiple commits to fix? the current system seems to want a one-to-one mapping of commit hash to CVE. Does this need to be expanded to allow multiple commits to be listed instead?
@gregkh Thanks - also is there any documentation regarding how responsible disclosure may work - the process allows kernel.org to assign a CVE for an issue before it is fixed but will you also share this with downstream distros ahead of the public disclosure of the CVE?
@gregkh I'm sorry but I don't see what not. The linux-distros mailing list exists exactly for this purpose https://oss-security.openwall.org/wiki/mailing-lists/distros
Some of this breaks rules governing CNAs (at least the updated WIP draft), like assigning CVEs to non-security bugs or forcing assignment of multiple downstream CVEs to describe a single upstream vulnerability. Assigning CVEs to EOL software is specified. If others assign EOL CVEs to Kernel it should not be invalidated. Invalidating CVEs since a patch is not public is equally dubious.
If that happened a dispute with a CNA can be raised to their TL-Root (in this case MITRE) for rule enforcement.