Live data from Hacker News

Dependency cooldowns turn you into a free-rider

calpaterson.com

111–120 of 131 posts

Re: Dependency cooldowns turn you into a free-rider

#111

My company implements cooldowns by never updating anything ever. (Send help)

Not updating things is an underappreciated strategy and a core principle of production environments: "if it ain’t broke, don’t fix it".

There are nuances of course, and things that are broken should be fixed, and unfortunately, they often don't want you to just fix what needs to be fixed, like security vulnerabilities. That's how stuff break constantly, you just wanted a patch for a buffer overflow, and you get an AI chatbot and your keyboard shortcuts disappeared.

Sometimes, they let you get only the things you want (i.e. actual fixes), it is important for companies that do serious business like banks, production lines, etc... They know it and charge good money for the privilege.

Re: Dependency cooldowns turn you into a free-rider

#112

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…

I take issue with the expectation that a business should take on the additional liability and risk of immediate adoption, just because this person on the internet thinks so. I’m doubtful they are going to pay the millions in liabilities that could result when something gets exploited, so it makes it hard to care what they think about it.

Re: Dependency cooldowns turn you into a free-rider

#113
I mean, speaking as an oss maintainer, there is an infinite list of things msft could do on npm and gh to make our lives better, but we might just have to accept that we’re on our own and have to deal with those platforms mostly as they are and dependency cooldown is just a pragmatic approach. :)

Re: Dependency cooldowns turn you into a free-rider

#114
This is as useless as the circular view that releasing dependencies for others to test makes you a free-rider on them using your stuff.

Which, honestly, I think it is fair to say that a lot of supply chains are lulling people into a false sense of what they do. Your supply chain for groceries puts a lot of effort into making itself safe. Your supply chain for software dependencies is run more like a playground.

Re: Dependency cooldowns turn you into a free-rider

#116

Earlier quoted context omitted.

"This plan works by letting software supply chain companies find security issues in new releases." If it was that easy we'd simply find all vulnerabilities before the release. If the supply chain companies can run the scanners you can (and should) run them too. Even if we assume there is more to it, it would make sense to let those companies do the work before GA. But it is not that easy. The true value comes from ma…

Consumers of dependencies aren't necessarily - or, I would argue, even typically - eyeballing them. The eye ballers in practice seem to mostly be hackers. Skipping the cooldown doesn't mean you're contributing eyes, it means you're volunteering to help the news of how many victims the attack swept up bigger. No-one is hurt by having the cooldown. Hackers could choose to also have a cooldown, but must balance the risk…

"Consumers of dependencies aren't necessarily - or, I would argue, even typically - eyeballing them."

No, but they are the reason software supply chain companies look into the releases. Cool downs very well shift the priorities and therefore hurt the ones not doing them, or doing shorter periods.

Re: Dependency cooldowns turn you into a free-rider

#117

> 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…

Linux distributions have done this in the past. It can work and can provide a good revenue source.

Re: Dependency cooldowns turn you into a free-rider

#118

> 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…

And it doesn't have to be separate companies. You can have cooldowns on most machines but reserve a few with no cooldowns that run vulnerability scanners & act like honeypots. Check for new activity after updates of the honeypot machines, e.g. connections to new domains, and flag what updated for review.

Re: Dependency cooldowns turn you into a free-rider

#119
Dependency cooldowns are theater. They will do nothing. Supply chain hacks get caught when someone gets pwned, and all this does is push the deadline out.

You find attacks via cross-organization auditing, like you do in Linux distros, and this doesn't do that.

Re: Dependency cooldowns turn you into a free-rider

#120
This article is a category error.

Dependency cooldowns are how you can improve your security on an individual level. Using them does not make you a free rider any more than using Debian instead of Ubuntu instead of Arch does. Different people/companies/machines have different levels of acceptable risk - cooldowns let you tune that to your use case. Using open source software does not come with a contract or responsibility for free, implicit pentesting.

Upload queues are how a package manager/registry can collectively improve security for it's users. I cannot implement an upload queue for just me - the value comes from it being done in a centralized way.

I'm in favor of both, though hopefully with upload queues the broader practice of long dependency cooldowns would become more limited to security-focused applications.

Post reply on HN