Fast upgrades [LWN.net]

Fast upgrades

Posted Apr 23, 2026 6:48 UTC (Thu) by roc (subscriber, #30627)
In reply to: Fast upgrades by ju3Ceemi
Parent article: Dependency-cooldown discussions warm up

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.

to post comments

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.