Dependency-cooldown discussions warm up [LWN.net]

By Joe Brockmeier
April 22, 2026

Efforts to introduce malicious code into the open-source supply chain have been on the rise in recent years, and there is no indication that they will abate anytime soon. These attacks are often found quickly, but not quickly enough to prevent the compromised code from being automatically injected into other projects or code deployed by users where it can wreak havoc. One method of avoiding supply-chain attacks is to add a delay of a few days before pulling updates in what is known as a "dependency cooldown". That tactic is starting to find favor with users and some language ecosystem package managers. While this practice is considered a reasonable response by many, others are complaining that those employing dependency cooldowns are free-riding on the larger community by letting others take the risk.

Everybody cool down

In November 2025, William Woodruff published a blog post advocating the use of dependency cooldowns to mitigate supply-chain attacks that affected open-source projects. In the post he looked at ten of the prominent supply-chain attacks that had taken place in 2024 and 2025, including the XZ backdoor, the attack on the Python ultralytics package, and the npm debug/chalk supply-chain attacks.

Each attack had the same basic structure: attack preparation, window of opportunity, detection of the attack, disabling of the compromised package, and then remediation. He said that the key thing to observe is that "once the attacker has moved into the actual exploitation phase, their window of opportunity to cause damage" is usually less than a week before the attack is detected by security vendors or other researchers.

Therefore, developers could avoid the bulk of the attacks by instituting a cooldown on dependencies of seven days. Woodruff also encouraged open-source projects to adopt cooldowns using dependency-management tools like Dependabot, and for packaging ecosystems to "invest in first-class support for cooldowns directly in their package managers". While not a perfect solution, he said, it would be a major improvement:

Cooldowns are, obviously, not a panacea: some attackers will evade detection, and delaying the inclusion of potentially malicious dependencies by a week (or two) does not fundamentally alter the fact that supply chain security is a social trust problem, not a purely technical one. Still, an 80-90% reduction in exposure through a technique that is free and easy seems hard to beat.

His blog post appeared on Hacker News, Lobste.rs, and elsewhere; it caught quite a few people's attention. In December, he published a follow-up that addressed common questions and objections.

For example, some people asked if cooldowns would be self-defeating. If everybody adopts them, then wouldn't the window of opportunity just include the cooldown period, thus negating the benefits? Woodruff countered with the observation that there are parties in the system—security vendors, open-source maintainers, and the package-index maintainers—with strong incentives to detect attacks before they reach users. In addition, universal adoption of cooldowns was "clearly not realistic: there are always going to be people who live at the edge. If those people want to be the proverbial canaries in the coalmine, that's their prerogative!"

He also listed a number of language ecosystems that had added or were exploring support for cooldowns in some of their tools, including Go, JavaScript, Python, and Rust. In March, Andrew Nesbitt did another round-up of the state of cooldown support in language package managers, dependency-update tools, and so forth. He looked at the package managers that currently support cooldowns, are in the process of adding support, as well as ecosystems where he couldn't find any evidence of plans to implement the feature. He noted that cooldowns are called "at least ten different configuration names across the tools that do support it", which made writing about the topic nearly as hard as the implementation of cooldowns in projects with multiple languages.

On April 6, the Python Package Index (PyPI) published an incident report following a supply-chain attack that affected the LiteLLM and Telnyx packages. The report included a section on how developers could protect themselves, which included dependency cooldowns as one way to avoid malware.

Wrong approach

On April 13, Cal Paterson published an argument against dependency cooldowns. He worried that the practice was being "fast-tracked into the basket of 'industry standard best practices'". It might look like an effective approach on the surface, he said, but cooldowns do not address what he felt was the core issue: "publishing and distribution are different things and it's not clear why they have to be coupled together".

He had a few complaints about cooldowns; for example, he argued that the cooldowns work "by free-riding on the pain and suffering of others" by treating those who grabbed updates right away as "unpaid, inadvertent beta testers for newly released packages". Even if the system works for individuals, he called it impossible to sustain "as a sensible or moral system" for an entire ecosystem to observe. Paterson also pointed out that it would require great effort on behalf of people who have to implement cooldown features:

Python has multiple package managers at this point (how many now? 8?). All must implement dependency cooldowns. And every project ever created has to configure the cooldown - which often isn't particularly easy or clear given that package managers often choose completely different ways to do it.

Upload queues

Instead of the cooldown approach, he argued that "the obvious alternative" was an upload queue: "Make new packages wait some period of time after they are published, before they are distributed." Publication would mean sending a release (a tarball, Ruby gem, Python wheel, etc.) to the central index for distributing packages. Distribution would be when the index begins serving packages to the public.

There would be an interim period where the package could be subject to automatic security scans, reviewed by the public, even downloaded by willing test subjects, but not widely distributed. He pointed to how Debian handles package distribution as a successful example of upload queues:

Debian stable effectively is an upload queue - the whole point is that it's made up of older releases that have already been subject to a QA process. The upload queue for language-oriented package managers need not be so comprehensive - but I do think there is something to take from the Debian example.

Debian, of course, has actual upload queues such as the new queue, but his larger point still stands. Upload queues not only provide more time to examine releases; the practice would also reduce the value of stealing release credentials. Many of the supply-chain attacks involved more than the insertion of malicious code, they also involve theft of release credentials so that the attacker can perform an unauthorized release of the package. If a package has to sit around for a few days, he said, the value of stealing release credentials goes down.

The wait period would serve to reduce or remove what he called "the entirely unnecessary element of surprise" when a new package release appears. Users would get advance notice of new releases.

And it's not just users who need advance knowledge. The upload queue period is also a good time to notify maintainers, to make sure that they are all indeed aware of the forthcoming release. "Notification: Release 2.4.1 has entered the upload queue" would be just the wake-up call required to avert a supply chain attack getting rolled out in many cases.

He acknowledged that cooldowns were useful in some situations and admitted he doesn't always want to be the first to upgrade: "the family TV set-top box is mission critical infra in my household". But he was against dependency cooldowns becoming community best practices. "I don't want my security to depend on someone else getting hacked first".

Paterson's post also picked up steam and made it to discussion sites. In the Lobste.rs thread about his post, Woodruff responded that Paterson's response was "directionally accurate" but missed a key part of the argument. "You're not free-riding on other maintainers, but instead on a number of 'supply chain security' companies that are financially incentivized to find malware as quickly as possible". He also agreed that upload queues were more desirable, and that instant distribution was a problem, but "it's also not something that's easy to take away now that it's been established as the norm for publishing language specific packages".

For now, since package indexes like PyPI have not announced plans to implement upload queues, users will need to rely on dependency cooldowns as a way to avoid being the victim of a supply-chain attack. It will be interesting to see what kind of progress is made over the next few years in implementing dependency-cooldown tooling across language ecosystems. Of course, attackers are also going to be watching and adapting their strategies as well—scanning for vulnerabilities during a cooldown period may catch many attempts to slip in malware, but it would be optimistic to bank on cooldowns working all the time.

[Thanks to Paul Wise for the topic suggestion.]

to post comments

Fast upgrades

Posted Apr 22, 2026 15:38 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (14 responses)

People will need the ability to quickly update a package (for security fix, for instance)

So then, you will need the ability to bypass the upload queue

And a new world of issue araises

Better put that responsibility in the hands of the users, so everybody can do what they want

Fast upgrades

Posted Apr 22, 2026 15:53 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

If you attach a CVE report (or equivalent) to an upload, this makes sense to me. This (probably?) involves a lot more work than just stealing a secret key. Additionally, if something *explicitly* requests the version, it should be made available (so that I can update dependent packages immediately without having to wait N days per dependency depth to update an entire stack).

Fast upgrades

Posted Apr 22, 2026 15:56 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

Everybody can issue CVEs

Fast upgrades

Posted Apr 22, 2026 19:03 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Sure, but a CVE is a big flare one might not want to attach to their trojaned upload.

Fast upgrades

Posted Apr 22, 2026 15:56 UTC (Wed) by bredelings (subscriber, #53082) [Link]

I think Debian handles this by allowing each upload to have an "urgency" tag, where the default is "urgency=median". But what if the attacker uploads with "urgency=medium"?

There is also the unstable -> testing delay. I run unstable myself, so I guess I'm labeling myself a willing beta tester?

Fast upgrades

Posted Apr 23, 2026 6:48 UTC (Thu) by roc (subscriber, #30627) [Link] (7 responses)

Indeed, this is a huge problem with the whole idea.

When a security fix is released you really need all your users to upgrade immediately. It's easier than ever with LLMs to very quickly analyze a change, determine if it fixes a security bug, and if it does, create an exploit. But if a maintainer can trigger instant upgrades, then a malicious maintainer can bypass cooldowns/queues.

Fast upgrades

Posted Apr 23, 2026 8:29 UTC (Thu) by kleptog (subscriber, #1183) [Link] (6 responses)

How do you not have the same problem the other way around? With cooldown timers you need to be able to override them for certain packages. Personally I prefer the upload queue idea, even if it was just a day. Then again, I'm not going to deploy most of the updates for some time simply because they're not important.

Honestly though, the "everyone needs to install security updates immediately" is really overrated for most people. We do the updates when we get notifications, but the vast majority of reported security issues are simply not relevant for our setup because they're all mitigated by other components in the system.

Some updates need to be coordinated, and people with very exposed systems need to pay more attention. But most of the time, it's not that important.

Fast upgrades

Posted Apr 24, 2026 10:00 UTC (Fri) by taladar (subscriber, #68407) [Link] (1 responses)

There is another downside to that idea.

Lets say I am one of the many small library maintainers who is actually using my own library in some other project. I discover I am missing a feature.

Today I can just add that feature to the library, publish it and immediately keep working on the other project using the published version.

With the upload queue idea I would have to work around the fact that my finished update (as far as I am concerned) is delayed before it is published, causing extra work, especially when it is not just one but potentially a chain of 3 or 4 packages each depending on the last.

Fast upgrades

Posted Apr 25, 2026 0:50 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

See https://lwn.net/Articles/1069144/. If you explicitly request the version (i.e., update Cargo.toml), you get it. But a blind `cargo update` would not. If I were implementing it.

Fast upgrades

Posted Apr 24, 2026 21:52 UTC (Fri) by roc (subscriber, #30627) [Link] (3 responses)

> Honestly though, the "everyone needs to install security updates immediately" is really overrated for most people. We do the updates when we get notifications, but the vast majority of reported security issues are simply not relevant for our setup because they're all mitigated by other components in the system.

Example: consumer software (desktop or mobile). Those applications are typically internet-facing and need immediate updates when security bugs are found.
Example: Web frameworks (both client and server side). Web sites need to be updated immediately when security bugs are found.

And when *some* updates need to be applied immediately in practice most people need to apply them *all* immediately when the vendor says so, because most users don't have the expertise to determine whether they need a specific update.

Fast upgrades

Posted Apr 27, 2026 9:31 UTC (Mon) by farnz (subscriber, #17727) [Link] (2 responses)

There's a stochastic element, though. Some vulnerabilities are "wormable", and really do need patching immediately, because you'll be probed in the next few minutes. Others, however are not - if the botnet time to probe for the vulnerability in your site means that it's uneconomic to probe more than 1% of sites in a day, then you have days before you're above the "more likely to be exploited than not" line.

Now, this comes with the caveat that if you're a high-value target, you're likely to be in the first day's worth of probes, but for many people, a week's delay is an acceptable risk - there are more likely causes of issues than a 10% chance of having the vulnerability exploited.

And for consumer software, it goes further. You do not need to upgrade until you're next about to run it; I have an app on my phone that I use rarely (once a month or so), and which has thus spent more time being upgraded than being used. I would not suffer any harm if, instead of upgrading every week or so, when a new update comes out, I upgrade once a month (when I'm next going to use it). Sure, I'd have vulnerable versions on my phone for longer - but it's not running code, so can't be exploited.

Fast upgrades

Posted Apr 27, 2026 11:12 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

Counter-point with the apps though, a lot of those rarely used apps are on there precisely because they need to be available and usable in situations where doing the update then and there is not feasible.

I don't travel by train that much but when I do I would be very upset to find at the train station that I need to go through a major update before I can check on which platform my train departs in 3 minutes, I don't need offline maps that often but when I do I really need the app to be usable without a connection,...

Fast upgrades

Posted Apr 27, 2026 12:38 UTC (Mon) by farnz (subscriber, #17727) [Link]

Sure - but the need is to update before leaving home when you're going to travel by train, not to update every day to get the latest bug fixes and improvements.

Worse, the "go through an update before I can check on which platform my train departs in 3 minutes" problem is just as much caused by "update immediately" as by "delay updates until I need the app" - if you update and leave home, a new update is made available while you're en-route, and then when you get to the train station, you can't access the app because you need to spend the next 15 minutes downloading an update via a congested network, you're going to be unhappy.

RE: Users

Posted Apr 24, 2026 4:13 UTC (Fri) by notriddle (subscriber, #130608) [Link] (1 responses)

If by "users", you mean "application end-users", then that's the worst possible place to put this responsibility.

Application users outnumber developers, so if every user made the decision on their own, then the total person-hours put into the decision making would be larger than if the responsibility defaulted [1] to developers, even though most users are doing the same, redundant, work.

Developers also outnumber registry operators, so implementing a policy within the package registry requires even less person-hours than expecting every developer to do it.

[1]: with an option for end users to patch the application and take responsibility into their own hands, assuming a perfect world where all applications are Free software

RE: Users

Posted Apr 24, 2026 10:01 UTC (Fri) by taladar (subscriber, #68407) [Link]

Obviously the users would delegate those decisions to whoever writes the default configs for their system (e.g. distro maintainers or the maintainers of their packaging tool) but the point is that it would be easier if the user side introduced the delay if they want to.

Or: Use less dependencies

Posted Apr 22, 2026 17:13 UTC (Wed) by jpeisach (subscriber, #181966) [Link] (3 responses)

One dependency can pull in tons of other dependencies, which can pull in tons of others. If left unchecked and unmaintained, this leaves the door open to malicious code just sitting unnoticed.

Or: Use less dependencies

Posted Apr 24, 2026 10:02 UTC (Fri) by taladar (subscriber, #68407) [Link] (2 responses)

I will never understand this kind of argument. You prefer code sitting unchecked and unmaintained and unnameable in some huge codebase of your single dependency?

Or: Use less dependencies

Posted Apr 24, 2026 16:16 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

It may or may not be the case that there's more poorly maintained code in one's dependency tree when using a few big dependencies rather than a host of small ones- it would be interesting to see a formal study on the topic- but that's a different thing from a supply chain attack. A supply chain attack is about a malicious actor trying to slip bugs or backdoors into code in the hopes someone will pick it up and use it, and that requires a kind of middle ground in terms of maintainership. If the code is completely unmaintained, there's no opportunity for an attacker to slip something in. If the code is actively maintained by a team, it will be hard for them to slip their attack code by the other maintainers. It's only when the code is maintained but there aren't a lot of other people looking at the patches that it becomes possible for an attacker to incorporate their backdoor. An attacker might try to slip something into a poorly maintained section of a big project, but they're a lot more likely to encounter some kind of code review than if they succeed in taking over a poorly maintained project.

Or: Use less dependencies

Posted Apr 27, 2026 10:05 UTC (Mon) by taladar (subscriber, #68407) [Link]

You are working from the assumption that in group maintained projects any given maintainer pays attention to all the patches in other parts of the code-base which I would consider about as - if not more - questionable than the idea that someone pays attention to patches in some small code-base that isn't theirs (e.g. one of their dependencies).

Python package managers

Posted Apr 22, 2026 18:06 UTC (Wed) by mvollrath (subscriber, #183387) [Link]

"Python has multiple package managers at this point (how many now? 8?). All must implement dependency cooldowns."

I can't tell whether this is a criticism of Python's package manager sprawl or dependency cooldowns.

"dependency cooldowns" versus "upload queues"

Posted Apr 22, 2026 20:34 UTC (Wed) by josh (subscriber, #17465) [Link] (1 responses)

The concept of "upload queues" seems like a combination of branding and defaults.

Defaults, because they're effectively a server-enforced default dependency cooldown with a duration of the delay required in the queue. So, instead of people opting *out* of being early adopters, people have to opt *in* to being early adopters, which would primarily be done by either 1) people doing security scans and similar analysis and 2) people in close collaboration who are building on each others' work (e.g. updating their own crate to use a new feature from the newly uploaded dependency).

That seems reasonable.

"dependency cooldowns" versus "upload queues"

Posted Apr 24, 2026 4:06 UTC (Fri) by marcH (subscriber, #57642) [Link]

Thanks for stripping the pseudo-moral considerations out of this, it helps see things more clearly.

https://calpaterson.com/deps.html

> Frankly, dependency cooldowns work by free-riding on the pain and suffering of others. Fundamental in the dependency cooldown plan is the hope that other people - those who weren't smart enough to configure a cooldown - serve as unpaid, inadvertent beta testers for newly released packages. If there's a problem, those poor saps get hacked, everyone notices that they got hacked, and the problematic package/executable is yanked before the dependency cooldowners' thresholds are reached.

This is ridiculous. You could (try to) forbid "stable" releases with the same line of reasoning! It's the exact same thing: sticking to existing bugs while waiting for others to find new bugs. But for some strange reason that does not shock anyone?

There is no "People should just...", never has been. The only way to stop people using a "bad" system is to offer a more appealing system - which to be fair, seems to be exactly what is proposed in the rest of the blog. Too bad it starts with the pseudo-moral stuff.

The reality is:
- Open-source projects get released and distributed freely in any way they want
- Distros and packagers consume versions and releases at any random pace that suit them.
- Users upgrade at any pace they feel is best for them.

Each "consumer" is free to decide for themselves and that freedom is more than fine - it's one of the essential software freedoms. That pace ALSO depends of course on release lifecycles and distribution systems offered, which make up some sort of consumption "API". Telling people that they are "using the API wrong" is mostly futile, always has been. If some API is used incorrectly too often, then it is a bad API and yes a better one (upload queues? something else?) must be put in place. It is unproductive to blame consumers (or anyone else really) for doing the "wrong thing" as long as only "bad" systems are available.

familiar

Posted Apr 22, 2026 21:34 UTC (Wed) by mattdm (subscriber, #18) [Link]

"Distro gatekeeping sucks! Distros suck! Who even needs 'em, these days?"

*wait a bit*

"Hey I know! Let's invent some sort of .... distribution. With gatekeeping!"

For what it's worth, in Fedora, we have updates-testing, where package updates sit for few days before going to the (on-by-default) regular updates repository.

Review?

Posted Apr 23, 2026 1:24 UTC (Thu) by pabs (subscriber, #43278) [Link] (15 responses)

I feel like code review and building from source is the way to avoid malware in the "supply chain".

Of course code review takes a lot of effort, so distributed social code review is needed. In that arena there is traditional distros (but they do minimal review), or there is cargo vet, but I feel like crev is better, but stagex folks found that crev needs some enhancements to support the full-source bootstrap use-case. So it isn't clear what the right answer is for code review.

https://news.ycombinator.com/item?id=47701394

Review?

Posted Apr 27, 2026 6:39 UTC (Mon) by tchernobog (subscriber, #73595) [Link] (14 responses)

> I feel like code review and building from source is the way to avoid malware in the "supply chain".

Unfortunately:

* in FOSS, we don't have many (good) reviewers, and most companies are freeloaders
* LLMs are producing harder and harder code to review, and in a quantity that puts considerable burden on maintainers
* the xz supply-chain attack shows that a bit more sophistication and planning from the attacker goes a long way; and it certainly was triggered when building from source and the code was reviewed

At some point, nobody will like it, but we need some kind of attestation process for FOSS, or a way to make companies invest resources into FOSS maintenance.

We'll see if the EU CRA law will help in this regard starting end of 2027. It can go both ways.

Review?

Posted Apr 27, 2026 8:25 UTC (Mon) by pabs (subscriber, #43278) [Link] (11 responses)

Yeah, review is in short supply, hopefully the CRA and or the many supply-chain attacks in recent years change that.

IIRC the xz attack payload was outside the VCS in the tarball, probably if people were doing reproducible tarball creation then it would have been caught.

What do you mean by attestation process for FOSS?

Have we seen any early effects of the EU CRA on companies yet? Are they talking about internally yet? IIRC so far I only saw people retracting their FOSS code from public view or reducing/eliminating their FOSS activities.

Review?

Posted Apr 27, 2026 9:23 UTC (Mon) by tchernobog (subscriber, #73595) [Link] (3 responses)

> What do you mean by attestation process for FOSS?

Some kind of way of reliably checking the author of a change, e.g. via proper code signing and on-boarding of developers. But with AI taking more and more the helm, this is getting to be a fuzzy concept anyway. There are some attempts with e.g. https://slsa.dev/

> Have we seen any early effects of the EU CRA on companies yet? Are they talking about internally yet?

I can only speak for my company, a EU mid-sized manufacturer (around 1'000 employees, ~ half a billion yearly revenue).

I can tell that:

* we are well aware of the requirements and are currently (and slowly: we are a hardware company too) working towards compliance
* this led to the creation of internal processes and structures that weren't there to respond requirements; this means also the establishment of an independent security team which was not there before, which is good
* we have now a (not huge, but not tiny) budget to spend on external contractors for fixing important open-source bugs, e.g. in u-boot, hashicorp vault, and more
* we have now full SBoM scanning for all dependencies and are taking timely action to reduce risks around unmaintained or buggy dependencies. So well maintained projects will get more attention, poorly maintained FOSS projects will get the kick

But I cannot speak of course for all companies; this is only anecdotal evidence that something is happening.

Review?

Posted Apr 27, 2026 13:01 UTC (Mon) by pabs (subscriber, #43278) [Link]

> Some kind of way of reliably checking the author of a change

What would be the point of that? As we saw with xz it isn't the author (or any aspect of their identity) that matters, its the code that matters. The many many times devs got hacked and their credentials were used to push malware. Or they sold their maintainership of their program (possibly including credentials), and spyware got added. Or that time an upstream released with a backdoor that would only activate on a particular Debian person's machine.

> via proper code signing and on-boarding of developers

Distros like Debian have both of those, but they don't have enough code review that they would always block any of the above.

Review?

Posted Apr 27, 2026 13:14 UTC (Mon) by pabs (subscriber, #43278) [Link] (1 responses)

A few suggestions for your FOSS processes:

Hope your license compliance is up to scratch too :)

Have a budget for contributing back financially with direct donations and or sponsorship.

Have a team working on contributing back code and otherwise participating in FOSS communities, joining forums, mailing lists, conferences etc.

The unmaintained/undermaintained projects are the ones that need you to assist them *more* *instead* of ditching them.

Since you are a hardware company, please consider making it simple to replace your software/firmware with open equivalents.

Review?

Posted Apr 27, 2026 13:36 UTC (Mon) by pizza (subscriber, #46) [Link]

> The unmaintained/undermaintained projects are the ones that need you to assist them *more* *instead* of ditching them.

...I wish more folks understood this.

(Not to mention that "undermaintained" being the overwhelming norm -- If you ditch those [sub-[sub-]] dependencies you're left with... doing all of the work yourself, I guess?)

Wrong tense?

Posted May 10, 2026 4:09 UTC (Sun) by ras (subscriber, #33059) [Link] (6 responses)

> Yeah, review is in short supply,

It was in short supply, until about 7 April. Not long after that, Firefox (on an unnamed OS I've forced to use) started updating itself every day. I had no idea why, and it drove me nuts. I later learned about Mythos, and a light bulb went off.

We can't be too far from the day when a review LLM of some sort becomes integrated into Debian's upload queue. I don't see any other way Debian can say, with a straight face, that the distribution uses its best efforts to give secure code to its users. My local LUG mate who packages Chromium for Gentoo tells me since about April 7, it went from 3 CVEs a week to 167 last week, and it's still going up. He was as perplexed as I was, for a while.

It's our brave new world I guess, one where we augment the limited human review pool with gigawatt power stations.

How long will the rapid update cycle last?

Posted May 11, 2026 10:03 UTC (Mon) by farnz (subscriber, #17727) [Link] (5 responses)

With any luck, this period of high CVEs is temporary. There's a lot of code out there, and the current round of automated tooling is finding a lot of security-relevant bugs in older code, but once we've got through this hump, it's plausible that the total amount of CVEs found will drop considerably.

How long will the rapid update cycle last?

Posted May 12, 2026 9:23 UTC (Tue) by ras (subscriber, #33059) [Link] (4 responses)

> With any luck, this period of high CVEs is temporary.

It's not obviously true.

If you look at the situation before AIs came along (say, a month ago), there seems to be a continuous stream of new CVEs. Not at the current AI-accelerated levels of course, but the point is they didn't go away despite what I assume is a constant level of both "intelligence" and effort put into it.

With AI, intelligence is no longer a constant. According to the AI companies it is doubling every 4 months. I don't trust that figure, but clearly it's increasing. AI also means effort is no longer constrained by the number of very clever, highly specialised people you can find. Instead it's constrained by how many power plants you can build, and the number of chips you can make. That means over the long term, the amount of effort a nation-state can put into it isn't constrained at all.

If there is some point where increasing the (intelligence × effort) stops yielding new CVEs, you're right. If that point doesn't arrive, nation-states will forever be building bigger and better AIs to find new CVEs.

However, there is another wrinkle. When I first read about Mythos my first reaction was like yours - there is a finite amount of code, so there can be only so many bugs. Now I'm not even sure about the "finite amount of code" thing any more. I have a personal friend who tells me he's written and deployed 1M lines of diffs so far this year. I know it's partially true. No human could produce 1M lines of diffs by hand [0]. But he did deploy them, and no other humans were involved in writing them. He could not have read them. Given he hasn't read them and given he uses the same Opus models I do, I know they are full of bugs. Not bugs your typical user will hit because a major portion of that 1M lines are tests, so from his perspective and his user's perspective he's done well. Sadly, CVEs are not the sort of bugs tests find.

I do not know what the way out of this is. I suspect languages in the mould of Rust and Wuffs that allow us to prove bugs of certain classes don't exist will be required, because I doubt you will be able to prevent the oncoming avalanche of AI-produced code.

[0] It takes about 1 billion tokens a day to produce that level of output.

How long will the rapid update cycle last?

Posted May 12, 2026 10:32 UTC (Tue) by patrick_g (subscriber, #44470) [Link] (2 responses)

> over the long term, the amount of effort a nation-state can put into it isn't constrained at all.

You assume the effort curve will tend to infinity?
It's clearly an S curve that will eventually become logarithmic. Since we haven't seen the inflection point yet, we shouldn't assume it tends to infinity.

How long will the rapid update cycle last?

Posted May 12, 2026 11:03 UTC (Tue) by ras (subscriber, #33059) [Link] (1 responses)

> It's clearly an S curve that will eventually become logarithmic.

Yes, logarithmic is probably where it will end up. But if code generation starts growing exponentially that doesn't help.

There is another worrying aspect to this. There is a tendency to view this new CVE finding capability as an "open source" problem. That's wrong. Have you ever fed obfuscated javascript to an LLM and asked it to translate it back to readable code? It does it so well, it's often more readable and better commented than the original.

This ability to understand code humans find inscrutable isn't limited to obfuscated javascript. Researchers found CVE-2026-3854 two weeks ago by using AI-augmented tools to analyse closed-source binaries in GitHub’s internal infrastructure. A suitably trained LLM has no trouble reconstituting the intent of machine code, and once it's done that the CVE hunt is on. The machine code can be obtained from a proprietary binary or a ROM.

The proprietary hunt for CVEs hasn't started in earnest yet, as the right sort of people haven't woken up to the possibilities. But they will, and then the hunters will have a field day. You may be right about it becoming logarithmic eventually, but I would not count on that saving us.

How long will the rapid update cycle last?

Posted May 12, 2026 12:02 UTC (Tue) by paulj (subscriber, #341) [Link]

How would you know the translated code is the same as the obfuscated or the machine code?

I'd fully expect the LLM to produce code that looks reasonable - it's been trained on large volumes of code after all. However, it's not at all the case that LLMs are perfect at preserving meaning/equivalence across translations.

How long will the rapid update cycle last?

Posted May 12, 2026 13:56 UTC (Tue) by farnz (subscriber, #17727) [Link]

My hope is that projects will start applying bug-finding tools (including LLM-based tools) in earnest to code during the review phase, in order to stop there being a stream of CVEs for their project, and that we will not simply accept that security bugs are found after deployment.

If I'm right, then the increased capability-effort product from AIs will not result in more CVEs; it will result in more patches being fixed before they're applied to the mainstream project.

Thus, even with orders of magnitude more code being written, I hope to see the number of CVEs found by LLMs going down, not because fewer bugs are being written, but because tool-assisted review means that the bugs are found and fixed before the code gets to the point where a CVE can be issued.

And part of why I think this is plausible is that the tools don't get tired. If you give a human reviewer 10x the code to review, they'll start to make more mistakes over time, and more bugs will get past them; in contrast, the tools can be run in parallel, and if there's 100x more code, well, you just have the tool spend 100x the time on finding the bugs.

Review?

Posted Apr 27, 2026 9:50 UTC (Mon) by kleptog (subscriber, #1183) [Link] (1 responses)

> LLMs are producing harder and harder code to review, and in a quantity that puts considerable burden on maintainers

Is this an actual data point or a fear? If the patches are too difficult to understand they should be rejected. Otherwise they'll never learn to produce readable code.

Junior developers have to be taught this as well.

Review?

Posted Apr 27, 2026 10:35 UTC (Mon) by TomH (subscriber, #56149) [Link]

I find that the difficulty is mostly not understanding the change, as a lot of the LLM driven PRs I see are actually fairly trivial, but rather the process of trying to carry out the review and interact with the nominal submitter.

The difference is that a human junior developer will (hopefully) learn from review comments, not just in terms of acting on then for the change under review, but also in terms of doing better with their next change.

An LLM will never do that, because it can't, so every change it makes is like a freshly minted junior developer and you're starting over from scratch every time. Sure in theory you could provide previous reviews as context but nobody's actually going to burn tokens on that.

Now if there's a human sitting between the LLM and the reviewer then maybe they will learn and will do a better job of prompting the LLM and reviewing it's output next time round but all too often any human that does exist is just copy-pasting the review comments back into the LLM and then copy-pasting the result back into the pull request and essentially just acting as a stenographer that adds no value to the process at all.

Frankly it's utterly soul destroying trying to review most of the LLM driver PRs we get for the OpenStreetMap web site code and I at least have mostly given up even trying.

Proprietary tools

Posted Apr 23, 2026 1:28 UTC (Thu) by pabs (subscriber, #43278) [Link]

> the attack is detected by security vendors or other researchers

How many of these attacks are only detected/detectable with proprietary tools being sold by those security vendors where the use of the tool for protecting FOSS is only a marketing opportunity for the company that will go away when the cost/benefit ratio becomes problematic?

Meanwhile...

Posted Apr 23, 2026 19:53 UTC (Thu) by GhePeU (subscriber, #56133) [Link] (50 responses)

... a compromised Bitwarden CLI package was uploaded to npm and was live for a couple of hours: https://www.bleepingcomputer.com/news/security/bitwarden-...

Cooldowns or upload queues, it doesn't really matter what is chosen (though I personally like the latter better), but introducing even a 24-hour delay would truly help because in most cases either the maintainer or somebody else in the company/team will quickly notice an unplanned release.

Meanwhile...

Posted Apr 24, 2026 10:08 UTC (Fri) by taladar (subscriber, #68407) [Link] (46 responses)

For the vast majority (in numbers) of packages that have a single maintainer who creates the package in their free time (not necessarily outside work but whenever they have time to work on it between the projects that are their actual main focus at work or between life events at home) they would not notice within a 24h period or even a 48h period since there is this little thing called weekends and also people are not generally in the habit of checking their own package releases constantly.

Meanwhile...

Posted Apr 24, 2026 12:42 UTC (Fri) by marcH (subscriber, #57642) [Link] (45 responses)

> they would not notice within a 24h period or even a 48h period since there is this little thing called weekends

Fine, make it 1 or 2 _work_ days. For vacations you should get coverage. If you are the only maintainer, then the project has "a bigger problem".

> and also people are not generally in the habit of checking their own package releases constantly.

Even if I'm very busy with other things and flooded with email as usual, I will 100% notice a "New X release!" notification if X is software I maintain! It's a rare and important enough event. If it's too routine, then something is probably wrong with X's release lifecycle (which is obviously a very important parameter in this entire discussion).

Projects with bigger problems

Posted Apr 24, 2026 14:22 UTC (Fri) by farnz (subscriber, #17727) [Link] (44 responses)

Part of the reason that these "supply chain" discussions end up in a mess is that there's at least three groups of projects out there:

Sole maintainer projects, done in spare time, low volume of users who'll care about a supply chain attack.
Sole maintainer projects, done in spare time, taken as a dependency by a big user who'll care about a supply chain attack.
Group maintained projects.

There's a reasonable fear that everyone's focused on the group maintained projects, where vacation cover etc is a sensible requirement, and not thinking about what the rules do to someone who thought they were in the "low volume of user" category, but in fact is in the "sole maintainer, taken as a dependency by a big user" category. And we have had examples over the years (libxml is the most recent I recall) where there are projects that are being maintained by a sole, dedicated and hardworking, maintainer, who needs to take a break for a bit, but is worried about what will happen to their big users if everything blows up while the maintainer takes 72 hours away from connectivity.

If you're on a 72 hour break from civilization (e.g. at a family event and not checking notifications daily), you won't notice a "New X release!" of something you maintain - you're not reading e-mail, so you won't see it. If your big users are depending on you seeing that and taking action within 48 hours of a new release, then there's an expectations gap. And it's much worse if you didn't know you had big users with such expectations - everything blows up because you thought it was just a few people playing with it for fun, but BigCorp is now hacked because you weren't paying attention to your notifications while dealing with dying relatives or whatever.

Projects with bigger problems

Posted Apr 24, 2026 17:05 UTC (Fri) by marcH (subscriber, #57642) [Link] (5 responses)

Agree one size does not fit all. Which is why cooldowns, timers, queue lengths and what else should be configurable. What matters at a macro level is the approach and high level architecture, not the low-level parameters.

> BigCorp is now hacked because you weren't paying attention to your notifications while dealing with dying relatives or whatever.

Every time Big pro relies on a poor, burn out and single maintainer, they have only themselves to blame. If you need better, pay up. It really is that simple. Business is all about trust relationships and managing risks and this just one of them - among many other "suppliers". Business as usual, moving on.

Projects with bigger problems

Posted Apr 24, 2026 17:32 UTC (Fri) by farnz (subscriber, #17727) [Link] (4 responses)

Right, but the high level approach we're discussing is "put a delay between maintainer publishing a new release and it being generally used, rely on the maintainer to take action if a release is bad to protect the users".

For group maintained projects, this is fine - one or more of the maintainers will be around to handle the notification that the release is bad, and will take action, But for sole maintainers, this runs into the "what if the maintainer is absent at no notice" problem; given that the maintainer can log off forever, a solution based on "maintainer takes action" is not enough.

One answer is social change - we accept that BigCorps will effectively take over sole maintainer projects by adding more maintainers, and if the sole maintainer doesn't want that, BigCorp will fork it and group maintain their fork, trying to stay in sync. This requires us to all accept that BigCorp will fork a lot of interesting projects, and that we have to consider "hostile forks" by big companies as "normal" - it's just BigCorp taking on responsibility for things they depend upon.

Projects with bigger problems

Posted Apr 24, 2026 17:52 UTC (Fri) by marcH (subscriber, #57642) [Link] (3 responses)

> given that the maintainer can log off forever, a solution based on "maintainer takes action" is not enough.

If the sole maintainer "logs off forever" (or a very long time), then there is a much "bigger problem": the project is just orphaned which means any discussion in release delays or other lifecycle questions is pointless.

> This requires us to all accept that BigCorp will fork a lot of interesting projects, and that we have to consider "hostile forks" by big companies as "normal" - it's just BigCorp taking on responsibility for things they depend upon.

I miss what there is to "accept" or "not accept" here... The ability to fork is intrinsic to software freedom. As is the freedom to pick the fork you prefer. Forking is pretty much the essence of free software and it happens frequently, that's just the way things are. BTW "hostile" is a very binary: forking has many shades of grey.

BTW any decent BigCorp has internal mirrors of most of their dependencies (to avoid outages if nothing else) and how they update those is effectively implementing "private cooldowns" already. The richest ones implement all sorts of human and/or automated reviews and inspections on updates already (which other "cooldowns" can happily rely on, as already noted in the main article)

These internal mirrors often have extra commits too, which may or may not be submitted upstream. So I guess you could already call them "forks" depending on some artificial set and personal thresholds.

Maybe they should provide their reviews to the world

Posted Apr 25, 2026 2:41 UTC (Sat) by DemiMarie (subscriber, #164188) [Link]

cargo vet and cargo crev already exist

Projects with bigger problems

Posted Apr 27, 2026 9:18 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)

What's needed is people to stop complaining when companies work in their internal forks first - all these devices shipped with a fork of the Linux kernel, for example, are doing the right thing from a supply chain security perspective, and you should expect them to have private patches that never get upstreamed.

Projects with bigger problems

Posted Apr 27, 2026 13:04 UTC (Mon) by Wol (subscriber, #4433) [Link]

> What's needed is people to stop complaining when companies work in their internal forks first

Isn't this what MOST people do, including FLOSS devs, work on an internal fork first?

The minimum required (and also maximum necessary) aka "necessary and sufficient" for companies to be considered "good FLOSS citizens", should be that their production repository (or a copy thereof) is world-readable.

If they want to make the effort to upstream their fixes (they should, it's in their interest, but it's their decision), then that's down to them.

And if the FLOSS developer wants to plunder their repository for good ideas and/or code, that's down to them!

Once we get over the current "OMG AI is finding exploits" scare, I would hope that the EU CRA encourages this to become the norm. Much less effort than doing stuff in-house.

Cheers,
Wol

Projects with bigger problems

Posted Apr 24, 2026 18:37 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (37 responses)

At the bottom, it's a huge free rider problem. There should never be a piece of critical infrastructure that everyone depends on that's supported by a single hardworking maintainer. Everyone who depends on that critical project needs to step up and provide some support, whether it's dedicating some of their developer time or just chipping in some money so the maintainer can afford to hire help. Much more than technical solutions, we need a change in people's expectation that they can freeload endlessly off other people's hard work.

Projects with bigger problems

Posted Apr 24, 2026 19:08 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> we need a change in people's expectation that they can freeload endlessly off other people's hard work.

"endlessly freeloading" is a *feature*, and IMO is the primary reason why F/OSS has been adopted so widely.

Projects with bigger problems

Posted Apr 24, 2026 19:58 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

And now people are discovering that zero cost comes with some downsides as well as upsides. If you want guaranteed rapid response to security problems, you're going to pay for it one way or another. In practice, chipping in to support the projects you depend on- whether that's direct financial contribution or paying for some developer time devoted to dependencies rather than your project- is still going to be way cheaper than paying for a proprietary solution.

Projects with bigger problems

Posted Apr 24, 2026 20:17 UTC (Fri) by marcH (subscriber, #57642) [Link] (34 responses)

> At the bottom, it's a huge free rider problem [...] There should never be... Everyone who ... needs to ... [...] We need a change in people's expectation [...]

Unless you live in a dictatorship (and even then...) there is no "People should just..." Social pressure has never worked beyond tribe-sized groups. People just try things, that's human nature at its core. Some people take big risks (like: depending on an orphaned project), others not. Some succeed, others not. Some learn (e.g: when hacked), others not. Some do as taught, others not. Some care, many not. Trying to stem that tide never got anywhere.

The only two effective actions are:

- Making things illegal. Vaguely effective sometimes. For instance: changing a software licence.
- Offering an alternative that people like better. For instance: DRM-protected streaming that Just Works over free P2P downloads of semi-random and possibly infected media.

In the past you could "educate" and influence a little bit but that's pretty much dead nowadays in this era of attention merchants and echo chambers. You can still publish stuff but that's more for personal "I told you so!" visibility and gain than for actual prevention.

Projects with bigger problems

Posted Apr 27, 2026 17:08 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (33 responses)

That's fair. Maybe a better way of making my point is to say that there's a free rider problem, and we will continue to suffer from all the knock-on effects of that free rider problem until there's some kind of solution. IMO, one part of the solution- probably the easiest part to deal with- is technical. Right now, even someone who would love to contribute to supporting all their upstream dependencies (including dependencies of dependencies to the Nth order) can't easily do it. That seems like something that could be fixed.

I'm imagining a FOSS forge that includes some kind of contribution system. Downstream projects register, and the forge can figure out what their dependencies are by looking at their code. Then they can sign up to donate, with a one-time or recurring contribution. The forge takes a little off the top to support its infrastructure and distributes the rest to whichever dependencies have registered to receive contributions. The trick is that any project that signs up to receive contributions has to agree to pass some of the money they receive upstream to their own dependencies, so indirect dependencies don't get left out. A project that doesn't want to receive contributions- maybe they decide the amount of money isn't worth the tax hassle- can decline them or just increase their pass-through to 100% so all the money gets sent to their dependencies. Any project that wants to receive contributions has an incentive to join the forge rather than some alternative, which should help build momentum for the idea. It's a purely technical solution, but at least it provides the infrastructure to make financial support for projects feasible.

Projects with bigger problems

Posted Apr 27, 2026 19:17 UTC (Mon) by marcH (subscriber, #57642) [Link] (32 responses)

Something like https://support.deezer.com/hc/en-gb/articles/360002471277... but for software - I like it!

GitHub, Gitlab and co. are currently in the best place by far to prototype something like this and get this ball rolling. Anyone working there and listening?

Of course, the devil is in the details and especially around the metrics. How do you stop the equivalent of bots listening to fake music and cashing in? As mentioned at this reference. As soon as there is money, there is an order magnitude more people trying to cheat or game the system. But still worth a try.

Projects with bigger problems

Posted Apr 27, 2026 20:53 UTC (Mon) by pizza (subscriber, #46) [Link] (7 responses)

> GitHub, Gitlab and co. are currently in the best place by far to prototype something like this and get this ball rolling. Anyone working there and listening?

Do we _really_ want to further reinforce these organizations' grip on F/OSS development?

> Of course, the devil is in the details and especially around the metrics. How do you stop the equivalent of bots listening to fake music and cashing in?

It's going to make us yearn for the good ol' days of "bug bounty" slop.

Projects with bigger problems

Posted Apr 27, 2026 21:25 UTC (Mon) by marcH (subscriber, #57642) [Link] (6 responses)

> > GitHub, Gitlab and co. are currently in the best place by far to prototype something like this and get this ball rolling. Anyone working there and listening?

> Do we _really_ want to further reinforce these organizations' grip on F/OSS development?

No, we want them to pay the initial cost of experimentation and then "steal" the lessons learned. As open-source usually does - including open-source "forges". Cause you can't really patent pure ideas yet (knock on wood) despite monopolies trying hard. Code may be flowing only one way, but you can't stop ideas from flowing in all directions.

Projects with bigger problems

Posted Apr 27, 2026 21:47 UTC (Mon) by pizza (subscriber, #46) [Link] (5 responses)

> No, we want them to pay the initial cost of experimentation and then "steal" the lessons learned.

... so you want them to take a[n ever-increasing] cut of money paid to F/OSS developers, instead of "just" advertising, datamining, and actively undercutting our professions?

The only "lesson" here is that these for-profit organizations do not, have never, and never will, have our backs. They view us as (a) a market to be captured and locked in, and (b) an expense to be minimized, if not eliminated entirely.

Projects with bigger problems

Posted Apr 27, 2026 22:42 UTC (Mon) by marcH (subscriber, #57642) [Link] (4 responses)

I'm aware this is a lost cause because antisocial media has been methodically destroying any sort of nuance or subtlety but.. the world is still a bit more complex than "they" versus "us". Yes: some things (and some people) are simple. Many others are not.

Projects with bigger problems

Posted Apr 27, 2026 23:21 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> The world is still a bit more complex than "they" versus "us". Yes: some things (and some people) are simple. Many others are not.

Sure, that's fine.

What I take issue with here is that this gives the big forge[s] another lever to use to lock folks in. Their sheer size/scope means they'd be the only ones able to meaningfully implement this trickle-down payment mechanism; anyone else trying to replicate it won't have anywhere near the reach to build a competitor after the fact. A classic example of network effects.

The only way I see this working is a through a truly neutral private collection society with a "public good" charter or a governmental department. And even then I don't see why the overwhelming majority of freeloaders would ever _voluntarily_ pay in.

Projects with bigger problems

Posted Apr 28, 2026 12:13 UTC (Tue) by marcH (subscriber, #57642) [Link] (2 responses)

> Their sheer size/scope means they'd be the only ones able to meaningfully implement this trickle-down payment mechanism; anyone else trying to replicate it won't have anywhere near the reach to build a competitor after the fact. A classic example of network effects.

I agree there would be significant network effects but I don't think they would be as bad as for music for instance. If only a few artists you like are missing from your favorite streaming service, then you're unlikely to subscribe to an extra one just for those. I bet most people just _buy_ that particular music instead of streaming it in that case. Whereas with a voluntary donation system, you can split your donations anyway you like any time you want. It seems quite different from that perspective.

Also, artists are getting ripped off because there is yet another indirection layer / middlemen: record labels. Not sure why these are still dominant in our Internet age (getting off-topic) but there's no rip-off equivalent for FOSS and I don't see why there would be any there.

Projects with bigger problems

Posted May 1, 2026 9:16 UTC (Fri) by massimiliano (subscriber, #3048) [Link] (1 responses)

IIRC, the Radicle (https://radicle.xyz) project was attempting to build a "trickle" system to transfer funds from projects to dependencies.

It was all blockchain-based, so it would not give power to monopolies.

I do not know what happened to it...

Projects with bigger problems

Posted May 1, 2026 9:50 UTC (Fri) by liw (subscriber, #6379) [Link]

I believe you mean Drips, drips.network.

Projects with bigger problems

Posted Apr 27, 2026 22:07 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (23 responses)

How do you stop the equivalent of bots listening to fake music and cashing in?

Because there's no money in that case. There isn't some big pot of ad money that gets shared between projects depending on how many other projects depend on them. Any money that comes in is associated with the project that's willing to give it, and that money goes to the project's dependency tree. A project can only bring in money if and to the extent that other projects willing to give money actually use it as a dependency.

The one way I can see to game the system is that as I described it, the money a project sends to its dependencies is divided equally rather than based on some measure of their relative importance. That gives programmers an incentive to game the system by multiplying dependencies. For example, if I have a project with only one dependency, all my pass-through money goes to that one project. Instead, I could write all the functions in my project as dependencies, one function per dependency, so most of the pass-through money would go to me instead of the other project. Even then, my project has to do something good enough to get people to depend on it in order to bring in any money.

Projects with bigger problems

Posted Apr 28, 2026 9:19 UTC (Tue) by farnz (subscriber, #17727) [Link] (22 responses)

The other way to game it is to vendor and obfuscate your real dependencies; in other words, instead of openly depending on OpenSSL, I vendor it and make some licensing compliant changes to make it "my" library. The result is that my "EasyCryptography" library has no dependencies not owned by me, and I get all the money, instead of my fair share.

Projects with bigger problems

Posted Apr 28, 2026 12:03 UTC (Tue) by marcH (subscriber, #57642) [Link] (5 responses)

> > Instead, I could write all the functions in my project as dependencies, one function per dependency, so most of the pass-through money would go to me instead of the other project

Rewards lines of code instead of each project equally? You could still game that but it would pretty obvious and look really bad.

With good test coverage tooling you could even reward lines of code actually used, excluding optional features.

> I vendor it and make some licensing compliant changes to make it "my" library.

That one looks pretty easy to detect automatically TBH. If not automatically, at least very obvious to humans.

Projects with bigger problems

Posted Apr 28, 2026 13:56 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

Code obfuscation techniques have been a thing for a long time, and are something LLMs are good at (while introducing new bugs, of course).

That makes detecting that "EasyCrypto" is in fact a wrapper around OpenSSL, and not a bunch of carefully written new cryptography code hard - because the obfuscation stops it being obvious. And sure, a detailed inspection by a human will catch this, and it'll be a scandal - but I can just clear off and disappear with my ill-gotten gains.

Projects with bigger problems

Posted Apr 28, 2026 14:08 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)

But a project must have users in the first place to have any gain.

> And sure, a detailed inspection by a human will catch this, and it'll be a scandal - but I can just clear off and disappear with my ill-gotten gains.

This assumes there will be a significant number of users for long enough with NONE noticing anything weird. And no AI check noticing anything either. It's not impossible of course but that seems a bit of stretch. Definitely not "routine" enough to threaten the model as a whole.

Projects with bigger problems

Posted Apr 28, 2026 14:55 UTC (Tue) by farnz (subscriber, #17727) [Link]

If it were genuinely uncommon, then we wouldn't be seeing issues with the supply chain to begin with - people would be noticing weird, and not using it.

The whole reason we're having this discussion is that people motivated by financial gain are attacking F/OSS software sources with the intention of clearing off with their ill-gotten gains - this is just an extra money path for them to take.

Projects with bigger problems

Posted Apr 30, 2026 10:39 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

We really don't want to encourage projects using more lines of code and more verbose programming languages.

Projects with bigger problems

Posted Apr 30, 2026 13:29 UTC (Thu) by marcH (subscriber, #57642) [Link]

Right, splitting across dependencies is not easy. Maybe it could simply be up to each project to value each of their own dependencies. They would be "politics" of course but projects should have the best knowledge. Also, "politics" is not always a bad word: an endangered dependency really difficult to substitute or re-implement could be valued more for no real "technical" reason and that would be OK.

Projects with bigger problems

Posted Apr 28, 2026 17:23 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

> The other way to game it is to vendor and obfuscate your real dependencies; in other words, instead of openly depending on OpenSSL, I vendor it and make some licensing compliant changes to make it "my" library.

And why would anyone buy your library, when OpenSSL is available?

Projects with bigger problems

Posted Apr 29, 2026 7:42 UTC (Wed) by farnz (subscriber, #17727) [Link] (14 responses)

My library is designed to be much easier to use for common tasks than OpenSSL, at the expense of removing all the power that OpenSSL exposes. In an honest world, it's a wrapper around OpenSSL to make it much easier to use; in this dishonest world, it pretends to be a simpler SSL library (and probably even points you at OpenSSL if you need the full power it exposes).

Projects with bigger problems

Posted Apr 29, 2026 16:36 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

So, like Boring SSL?

Your library will need to add some additional functionality for people to prefer it to raw OpenSSL, especially in the LLM age.

Projects with bigger problems

Posted Apr 30, 2026 10:41 UTC (Thu) by farnz (subscriber, #17727) [Link] (11 responses)

Sure - but if I can find such a niche, I can game the system to get all the money, rather than just the share I earn by providing a nice wrapper.

Projects with bigger problems

Posted Apr 30, 2026 13:31 UTC (Thu) by marcH (subscriber, #57642) [Link] (10 responses)

If a system can be gamed only in rare niches, then it's a pretty good system. It means "manual" policing is minimal and doable.

Projects with bigger problems

Posted Apr 30, 2026 13:48 UTC (Thu) by farnz (subscriber, #17727) [Link] (9 responses)

Quite the opposite - you'll have the spam problem, which means that manual policing is not doable (since you're flooded by possible attacks), along with attackers going for every niche they can with libraries that have everything they depend upon vendored instead of credited, so that they can get the full payment, rather than letting the people they depend upon get some income.

Projects with bigger problems

Posted Apr 30, 2026 14:34 UTC (Thu) by marcH (subscriber, #57642) [Link] (8 responses)

For money to be there you need users to give some and I still didn't get how you get a significant number of users with your scheme, sorry.

Projects with bigger problems

Posted Apr 30, 2026 14:48 UTC (Thu) by farnz (subscriber, #17727) [Link] (7 responses)

You just need to flood out the catalog with so many projects in each area of application that, while any single project doesn't get much money, anyone trying to find something useful in there is likely to pick up one of your projects, and not one that's honest.

This is also a problem in retail - if you search eBay, AliExpress, Amazon or other marketplace sites for something fairly generic (as opposed to something that has active trademark protection), you're quite likely to be overwhelmed by large numbers of apparently identical versions from lots of random companies that you don't recognise.

Projects with bigger problems

Posted Apr 30, 2026 17:33 UTC (Thu) by marcH (subscriber, #57642) [Link] (6 responses)

I have never seen anyone looking for software looking for "something generic". I really don't think this is how it works.

Projects with bigger problems

Posted Apr 30, 2026 17:37 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

I see it all the time - you want a HTTPS client, or a WiFi manager, and unless you know the name of the project you want already, you search for a generic term like that. And those terms will be absolutely overloaded with automated spam options - unless you know already that cURL is your HTTPS client of choice, or that you want IWD to manage WiFi connections, you're going to be facing people flooding out the things you want.

Not to mention typosquatting and other attacks on the humans doing this - you think you're donating to cURL, but you're donating to cURI instead.

Projects with bigger problems

Posted Apr 30, 2026 17:46 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

When people are overloaded with generic offers, they usually turn to stats, reviews and other reputation systems and for software that is more than enough, you just need to invest more than a few minutes.

I think you also keep losing sight that we are discussing _voluntary_ contributions to... projects randomly picked up in a list? I'm not saying this would never happen, I'm just saying it will be small enough not to harm the system as a whole. Same for typosquatting.

For a bad actor typosquatting, security and owning target systems is probably more valuable than collecting contribution pennies.

Projects with bigger problems

Posted Apr 30, 2026 18:02 UTC (Thu) by farnz (subscriber, #17727) [Link]

Right, and what I'm saying is that the system will not work, because as soon as there's money in the system, people will game stats, reviews, reputation systems, and more.

As a result, either you have no contributions (hence no money, hence no attackers), or you're faced with a flood of attackers making the system more expensive to run. The only reason Temu and places like it survive is that, with a flood of attackers, you still have people who have to pay to get the goods at all; but if I don't have to pay, why would I risk paying on a platform that's full of scams?

Projects with bigger problems

Posted Apr 30, 2026 17:42 UTC (Thu) by pizza (subscriber, #46) [Link] (2 responses)

> I have never seen anyone looking for software looking for "something generic". I really don't think this is how it works.

Even if there is only one module in the entire namespace that implements $functionality, how exactly are random software developers supposed to know what its name is without first searching for "$language module for $functionality" ?

Projects with bigger problems

Posted Apr 30, 2026 17:54 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

I meant no one looking for software is going to think "Oh, I can choose between 50 'generic' options for this, I'm spoiled with choice, this is great! Lucky me".

Software being all fixed costs and network effects, when you see 50 different options you immediately know that at least 47 are garbage if not more. Once you have 3 viable left, you are still depressed because now you need even more time to evaluate the 3 left, as you know dependencies are really hard to change and picking up one is pretty long-term commitment.

This is pretty much the opposite of buying "generic" stuff on Temu.

Projects with bigger problems

Posted Apr 30, 2026 17:59 UTC (Thu) by farnz (subscriber, #17727) [Link]

No, they're going to think "oh, this platform is awful - it's got 5,000 options, and I can't see how I find the legitimate ones in all the junk, so I'm not going to donate to anything on this platform at all". And thus, the platform ends up dead.

Projects with bigger problems

Posted Apr 30, 2026 11:08 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

seesms to have some good value then!

Meanwhile...

Posted Apr 25, 2026 2:06 UTC (Sat) by roc (subscriber, #30627) [Link] (2 responses)

> but introducing even a 24-hour delay would truly help

Unfortunately we are now in a world where 24 hours is more than enough time for AI to reverse engineer bugs, develop exploits and deploy them.

Meanwhile...

Posted Apr 27, 2026 16:22 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

Note, though, that the original motivation for the delays was specifically about supply chain attacks, meaning deliberately introduced backdoors. The attacker in a supply chain attack doesn't need any time to figure out how to exploit it; if they need to wait any time it's for people to install the software so they have some targets. Deliberately introducing a delay is there to give the defenders, and the defenders' LLM, time to detect the backdoor before the attacker has a chance to exploit it.

Meanwhile...

Posted Apr 28, 2026 10:23 UTC (Tue) by taladar (subscriber, #68407) [Link]

That is not really true for general supply chain attacks though. Only very targeted attacks need no time on the attacker's side. Broadly distributed ones still need the attacker to discover who actually used the code they backdoored and which of those targets are worth attacking further.

Meanwhile the comment you replied to is probably about all the security fixes whose rollout would also get delayed with this.

Maintainers can wait for code review but not for publish review?

Posted Apr 27, 2026 13:04 UTC (Mon) by cyperpunks (subscriber, #39406) [Link]

Review and testing of any code change is the norm these days, however when a release is finished and ready to published, maintainer don't have to review the content of the actual artifacts delivered to users?

What is then the point of performing code review and testing when the actual shipment contents something else than what has been reviewed and tested?

The publish step is the most important in the whole process as that decide the actual content to users.

If Dev don't care what artifacts is published, then why maintain the software in the first place?