Hacker News Reader

Comment by dominicq | Hacker News Reader

> 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, with manual triggers for those libraries which are not in the top N.

Their incentive is to be the first to publish a blog post about a cool new attack that they discovered and that their solution can prevent.

View on HN

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 and security checks before making it the default?

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.

FTA, "even make the queued releases available for intentional, explicitly volunteering beta testers to try out." Under the proposed system, you have to opt in to the insecure early releases. Rather than opting out of them. Which seems like a more secure default!

> insecure early releases

This is the wrong framing.

There's no free lunch here. Delays in publishing not only slow down attacks, they also slow down critical security patches. There's no one-size-fits-all policy here, you're at risk either way.

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

This is true but that doesn't make "Dependency cooldowns turn you into a free-rider", the title of the article and the subject of the first part, true.

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.

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

Security people should love a delay in distribution as packages wait in the queue. Then they have an opportunity to report before anyone else.

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.

I feel like this is false. These companies mostly seem to monitor social media and security mailing lists with an army of LLMs and then republish someone else's free labor as an LLM slop summary as fast as possible whilst using dodgy SEO practices to get picked up quickly.

They do do original work sometimes. But most of it feels like reposted stuff from the open source community or even other vendors

"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 many eye balls and then we are back at cooldowns being some eye balls grifting others.

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 of competing groups exploiting vulnerabilities first against the reward of a bigger pool of victims to exploit, and without collusion that still favours early exploits over held ones.

"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.

Reply on news.ycombinator.com