So CopyFail CVE-2026-31431 is a thing.
-
@corsac @joshbressers @wdormann @Viss Linux makes it very "easy", just update your kernel to the newest version. What's preventing that from happening for your systems?
@gregkh @joshbressers @wdormann @corsac @Viss sooo many things.
But they are not inherent to the kernel. Most software producing org are organised to slow down deployment and delivery. People are scared of changes. And the tooling to make changes less scary is ... Not well invested into.
-
@gregkh @joshbressers @wdormann @corsac @Viss sooo many things.
But they are not inherent to the kernel. Most software producing org are organised to slow down deployment and delivery. People are scared of changes. And the tooling to make changes less scary is ... Not well invested into.
@gregkh @joshbressers @wdormann @corsac @Viss
Here is a small thing to think about.
The whole point of cve is to allow you to not update.
That may sound strange but think about it. The whole point is that as long as we do not reveive a massive panic alert from this limited source, then we do not have to update.
This is why it has become so central. Orgs are fundamentally wired against updates.
-
@joshbressers @gregkh @wdormann @Viss i have thoughts
1. It probably was like that before LLMs even. Look at your dependency reports for all the projects your company have. It has not been clean in nearly a decade. Not because too many vulnerability. Because too much FOSS. These were tools (and compliance) built with the vendors world of the 90s/early 00s in mind.2. I think we can go far faster. Faaaar faster. Our tooling is crap, noone use it and we have not even tried. But i think we have different toolings and going faster in mind. See the github "want" list from @andrewnez for one take on it. I have more.
3. There are systemic problems there that can be looked at systemically. It will not be a quick fix but eh. We have been living with this for years, we don't need a quick fix.
4. The whole idea of vuln feed is probably dead though. It never made a lot of sense in a language package manager enabled world anyway. Only in this 90s/00s view.
5. Part of going faster is probably going to be a software engineering organisation of work problem. The SDLC, the Agile and the whole way we produce code in commercial software is probably the biggest problem here. It is fundamentally inefficient, probably for systemic reasons (i have some theories there, with some evidential support from research). But that links to the rest.
@joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na it would be cool if vulnerability databases could synchronize with each other using activitypub or similar
-
@gregkh @joshbressers @wdormann @corsac @Viss
Here is a small thing to think about.
The whole point of cve is to allow you to not update.
That may sound strange but think about it. The whole point is that as long as we do not reveive a massive panic alert from this limited source, then we do not have to update.
This is why it has become so central. Orgs are fundamentally wired against updates.
@Di4na @gregkh @joshbressers @wdormann @Viss that’s call risk management and it’s not necessarily a bad thing. And people have been (and still are) burned by updates. I don’t think it’s a good reason to never update but I can’t blame people for being cautious, especially since I’m not in their shoes and don’t know all their concerns
-
@joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na it would be cool if vulnerability databases could synchronize with each other using activitypub or similar
@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na If only we had some sort of... "Open Source" Vulnerability Database.. as a clearing house. Some sort of non-profit org could maintain it probably
someone should get on that
-waits for attacks from angry squirrels-
-
@joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na it would be cool if vulnerability databases could synchronize with each other using activitypub or similar
@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na The Vulnerability Lookup folks are working on something close
GCVE-BCP-03 - Decentralized Publication Standard
Decentralized Publication Standard Version: 1.5 Status: Published (for public review) Date: 2026-03-10 Authors: GCVE Working Group BCP ID: BCP-03 This guide is distributed under CC-BY-4.0. Copyright (C) 2025-2026 GCVE Initiative. Introduction This document describes the decentralized publication model that allows GNAs to publish their vulnerability information directly, without relying on a centralized system. It also outlines the access methods GNAs use to distribute published vulnerabilities through various mechanisms.
(gcve.eu)
-
@Di4na @gregkh @joshbressers @wdormann @Viss that’s call risk management and it’s not necessarily a bad thing. And people have been (and still are) burned by updates. I don’t think it’s a good reason to never update but I can’t blame people for being cautious, especially since I’m not in their shoes and don’t know all their concerns
@corsac @gregkh @joshbressers @wdormann @Viss I mean, yes, this is kinda my point above
But also, they are also burned (and not less) by not updating. It is just not considered the same way in the stats and not seen as the same thing. Because not updating is always in the past *after* the incident -
This post got into my head. I think you're right, the days of coordination are over
So I wrote it down
https://opensourcesecurity.io/2026/05-vulnerability-economics/@joshbressers The one case where downstream vendors can still get advance notice? When they're actually directly employing people on the project level security response teams (which is a potentially double edged sword from the project's side, since it means volunteers don't have to do security response without compensation for their time, but risks bringing those dubious corporate incentives you mentioned up to the project level)
-
@corsac @gregkh @joshbressers @wdormann @Viss I mean, yes, this is kinda my point above
But also, they are also burned (and not less) by not updating. It is just not considered the same way in the stats and not seen as the same thing. Because not updating is always in the past *after* the incident @Di4na @gregkh @joshbressers @wdormann @Viss unfortunately I think there a lot of people (IT services) having been burned more badly by updating than not updating. I still think people should do it (especially because mass vulnerability exploitation seems to usually happen for stuff fixes months ago) but still just blaming them for not doing doesn’t work. Not sure it’s really the Linux kernel the concern here though.
-
@Di4na @gregkh @joshbressers @wdormann @Viss unfortunately I think there a lot of people (IT services) having been burned more badly by updating than not updating. I still think people should do it (especially because mass vulnerability exploitation seems to usually happen for stuff fixes months ago) but still just blaming them for not doing doesn’t work. Not sure it’s really the Linux kernel the concern here though.
@corsac @gregkh @joshbressers @wdormann @Viss I think it is not true, but it is because we do not burn people for not updating
-
This post got into my head. I think you're right, the days of coordination are over
So I wrote it down
https://opensourcesecurity.io/2026/05-vulnerability-economics/@joshbressers @gregkh @wdormann @Viss this may be true for the Linux kernel, especially with the resignation that the Linux CNA will assign a CVE for most reports, but it doesn't align with my anecdotal experience as glibc CNA. It's likely because we have significantly less volume (12 so far this year, with roughly twice as many reports) and we tend to be picky about what we assign to a CVE id to.
I'd argue that the kernel is special here and doesn't represent the ecosystem.
-
@gregkh @joshbressers @wdormann @corsac @Viss
Here is a small thing to think about.
The whole point of cve is to allow you to not update.
That may sound strange but think about it. The whole point is that as long as we do not reveive a massive panic alert from this limited source, then we do not have to update.
This is why it has become so central. Orgs are fundamentally wired against updates.
-
@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na If only we had some sort of... "Open Source" Vulnerability Database.. as a clearing house. Some sort of non-profit org could maintain it probably
someone should get on that
-waits for attacks from angry squirrels-
-
@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na The Vulnerability Lookup folks are working on something close
GCVE-BCP-03 - Decentralized Publication Standard
Decentralized Publication Standard Version: 1.5 Status: Published (for public review) Date: 2026-03-10 Authors: GCVE Working Group BCP ID: BCP-03 This guide is distributed under CC-BY-4.0. Copyright (C) 2025-2026 GCVE Initiative. Introduction This document describes the decentralized publication model that allows GNAs to publish their vulnerability information directly, without relying on a centralized system. It also outlines the access methods GNAs use to distribute published vulnerabilities through various mechanisms.
(gcve.eu)
@Le_suisse @ariadne @gregkh @wdormann @Viss @andrewnez @Di4na
Yes! The #GCVE folks are really on the ball about all this
I would be willing to bet a milkshake they will be one of the more authoritative sources in the future
-
@joshbressers The one case where downstream vendors can still get advance notice? When they're actually directly employing people on the project level security response teams (which is a potentially double edged sword from the project's side, since it means volunteers don't have to do security response without compensation for their time, but risks bringing those dubious corporate incentives you mentioned up to the project level)
I'm not opposed to a company employing people at a given project to get some advanced notice
The devil is in the details, but I think in many cases it could work
-
@joshbressers @ariadne @gregkh @wdormann @Viss @andrewnez @Di4na (that’s the joke)
-
@joshbressers @gregkh @wdormann @Viss this may be true for the Linux kernel, especially with the resignation that the Linux CNA will assign a CVE for most reports, but it doesn't align with my anecdotal experience as glibc CNA. It's likely because we have significantly less volume (12 so far this year, with roughly twice as many reports) and we tend to be picky about what we assign to a CVE id to.
I'd argue that the kernel is special here and doesn't represent the ecosystem.
@siddhesh_p @gregkh @wdormann @Viss
Every project is really its own ecosystem
I think glibc does a really good job with CVEs
But I suspect if you go from 12 a year to 12 a month your process will have to change
It's possible you would adopt the "give it a CVE and move on" approach, or because there is so much attention from the distros you could get some extra help to deal with the volume
-
@joshbressers @ariadne @gregkh @wdormann @Viss @andrewnez @Di4na (that’s the joke)
-
I'm not opposed to a company employing people at a given project to get some advanced notice
The devil is in the details, but I think in many cases it could work
@joshbressers Yeah, I think it's generally a good thing myself (the responsiveness that's desirable for a good SRT isn't reasonable to expect from volunteers, and involving vendor/redistributor employees is one way of addressing that gap). It "just" needs to be done with awareness of the potentially conflicting interests.
-
@gregkh @icing @joshbressers @wdormann @Viss "it is not easy to decide who should be on the list, so we can not even have list with Linux distros hat should obviously be on list" argument seems rather unconvincing though.
To reiterate what he said, they do have a list its everyone, when they publish the CVE.
