Live data from Hacker News

Dependency cooldowns turn you into a free-rider

calpaterson.com

71–80 of 131 posts

Re: Dependency cooldowns turn you into a free-rider

#71

Not everyone has the same update cycle. That's not free-riding. The framing around not being on the latest version as irresponsible doesn't hold up.

Yeah this. If I don't buy the new iPhone XX.0 but instead wait for XX.1, which could include software and hardware fixes, does that make me a free rider?

> If I don't buy the new iPhone XX.0 but instead wait for XX.1, which could include software and hardware fixes, does that make me a free rider?

Yes, that's what free-riding is.

And the major problem, which the article touches on but doesn't do much to explore, is that if you characterize this as "responsible behavior", it will automatically cause itself to fail, because all of the benefits come from free-riding. The only benefit of waiting is that other people might not do it, and those people will drive improvements. If everyone waits, the only thing that happens is that (1) improvements will take longer to be developed, and (2) everyone experiences exactly the same problems as they would have if no one waited. There's no benefit, but increased cost.

Imagine you and everyone you know are inside a minefield. You need to leave, because you have no water.

Does waiting until enough people have killed themselves to establish the outline of a safe path out make you a free-rider?

What is there to be gained by instituting a waiting period before any attempt to leave?

Re: Dependency cooldowns turn you into a free-rider

#72
post #42

Earlier quoted context omitted.

I’ve never seen code that is downloaded run itself. Why not be the change you want to see in the world and run sudo or spawn your browser in a jail. Or download as another user.

Welcome to npm post-install scripts... https://docs.npmjs.com/cli/v11/using-npm/scripts

glad pnpm disables those by default!

Re: Dependency cooldowns turn you into a free-rider

#73

> 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. This is wrong to an extent. This plan works by letting software supply chain companies find security issues in new releases. Many security companies have automated scanners for popular and less popular libraries, w…

Sure, but the alternative the author proposes not only allows for time for those scanners to run but explicitly models that time as a formal part of the release process . Status quo (at least in most language's package managers) + cooldowns basically means that running those checks happens in parallel with the new version becoming the implicit default version shipped to the public. Isn't it better to run the safety a…

Or: make the client side automatically pick the previous version if the latest is too new.

That's a lot less work than putting an extra validation step into the publishing pipeline. And with sane defaults it lets the user make an informed decision when special circumstances arise.

Re: Dependency cooldowns turn you into a free-rider

#74

Earlier quoted context omitted.

Sure, but the alternative the author proposes not only allows for time for those scanners to run but explicitly models that time as a formal part of the release process . Status quo (at least in most language's package managers) + cooldowns basically means that running those checks happens in parallel with the new version becoming the implicit default version shipped to the public. Isn't it better to run the safety a…

Or: make the client side automatically pick the previous version if the latest is too new. That's a lot less work than putting an extra validation step into the publishing pipeline. And with sane defaults it lets the user make an informed decision when special circumstances arise.

That's exactly the "dependency cooldowns" we have right now that the author argues against.

Re: Dependency cooldowns turn you into a free-rider

#75
I don't think this is wrong, but I don't think it will be a problem in practice. One alternative to cooldowns is commercial repackagers, like Chainguard. As long as there are commercial clients who want a validated source of packages, there'll be a market for providing a security wrapper around private package repositories. It's in their interests to a) be quick to get new package versions through, and b) share any fixes they make or any problems they find with the upstream, because it's always going to be cheaper to do that than maintain a long tail of proprietary security patches (not to mention the risk of the clients complaining about either licence problems or drift from the original projects).

That means there's an incentivised slot in the ecosystem for a group of package consumers who are motivated to find security problems quickly. It's not all on the wider development community.

Re: Dependency cooldowns turn you into a free-rider

#76

Earlier quoted context omitted.

Sure, but the alternative the author proposes not only allows for time for those scanners to run but explicitly models that time as a formal part of the release process . Status quo (at least in most language's package managers) + cooldowns basically means that running those checks happens in parallel with the new version becoming the implicit default version shipped to the public. Isn't it better to run the safety a…

Agreed that the upload queue solves this problem, but, one thing about the current system is it lets people choose where on the continuum they want to be depending on their risk/reward profile.

I would suggest the current system fails to efficiently choose (as you have to align multiple pathways, like updates, "manual" installs, adding new packages), and so effectively there's only the illusion of choice. Switching instead to a queue not only means that there's time for QA/security scans, but it's much easier to make the choice to speed up than slow down.

Re: Dependency cooldowns turn you into a free-rider

#77
post #32

That can sometimes be true, but the reverse is also problematic: Uniform automatic updates can turn some users who were happy with the status-quo into unwitting guinea pigs for unexpected features and changes, without informed consent. All else being equal, I'd rather the people who desire the new features be the earlier-adopters, because they're more likely to be the ones pushing for changes and because they're more…

The issue is single-channel feature and security updates.

Re: Dependency cooldowns turn you into a free-rider

#78
post #20

It keeps me thinking that every company loves "those guys" who create OpenSource but won't give them a broken penny, nor support them in any other way Servants! Just do your open source magic, We're impatient! Ah and thanks for all the code, our hungry hungry LLMs were starving.

As much as I think what you say in general holds, there's at least something against it here:

>And the PSF even recently took in $1.5m from Anthropic for, among other things: supply-chain security.

Re: Dependency cooldowns turn you into a free-rider

#79
post #74

Earlier quoted context omitted.

Or: make the client side automatically pick the previous version if the latest is too new. That's a lot less work than putting an extra validation step into the publishing pipeline. And with sane defaults it lets the user make an informed decision when special circumstances arise.

That's exactly the "dependency cooldowns" we have right now that the author argues against.

[dead]

Re: Dependency cooldowns turn you into a free-rider

#80

Having skimmed the article I understand the title. While I agree on some level I wholly disagree on another: to me "dependency cooldown" is a way to automate something as old as time: the late-adopter-laggard. Although I am a tech-nerd and like the latest stuff. I have almost always let other people try it out first. I've missed out on some things because of it but if you are more conservative in your actions it just…

The problem is making it a default (or even popular). If everyone tries to move themselves later in the chain, you just moved detection later in the chain as well

Yes. But also infection with a malicious package. I don't want anybody to be hacked and also don't want everybody to be hacked at the same time. If I am managing multiple software components with different levels of reliability requirements I certainly would stagger updates and updates to dependencies using "dependency cooldowns". I don't fault anybody for using them. As it stands I am very conservative with dependencies/updates in general and not using "dependency cooldowns" yet.
Post reply on HN