Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dependency cooldowns turn you into a free-rider

calpaterson.com

Post reply on HN
Print view View original

121–130 of 131 posts

Re: Dependency cooldowns turn you into a free-rider

#121

Post by kibwen »

crabmusket wrote: post #97
Ozzie_osman wrote: post #40

Earlier quoted context omitted.

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.

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.

Re: Dependency cooldowns turn you into a free-rider

#122

Post by ball_of_lint »

JR1427 wrote: post #63

A central package cooldown is not really any different to individual cooldowns. The main reason for the cooldown is so security companies can find the issues, not that unwitting victims will find them. One problem of the central cooldown is that it restricts the choice to be able to consume a package immediately, and some people might think that a problem.

They are categorically different.

I can implement a dependency cooldown for my org and benefit from it immediately. An upload queue gets its value from being done centrally and allowing security researchers early access and the ability to coordinate.

Re: Dependency cooldowns turn you into a free-rider

#123

Post by kibwen »

onionisafruit wrote: post #10

The people who will benefit from a cooldown weren’t reviewing updates anyway. Without the cooldown they would just be one more malware victim. If you don’t review code before you update, it just makes sense to wait until others have. Despite what the article says, the only people who benefit from a rush to update are the malware spreaders.

> Despite what the article says, the only people who benefit from a rush to update are the malware spreaders.

And, you know, all the downstream users trying to install fixes for zero-days.

Re: Dependency cooldowns turn you into a free-rider

#126

Post by 12_throw_away »

It's weird, because I'm not aware of any OSS licenses or authors who say "you are expected to upgrade to the most recent release of this package as soon as it comes out so that you'll get infected with any malware it might contain."

Good thing the internet is here to lecture me about all the secret obligations I have incurred by creating and using open source software!

Re: Dependency cooldowns turn you into a free-rider

#127

Post by vlovich123 »

calpaterson wrote: post #23
vlovich123 wrote: post #16

Earlier quoted context omitted.

This literal example is actually addressed by the Debian example - the security team has powers to shuttle critical CVEs through but it’s a manual review process. There’s a bunch of other improvements they call out like automated scanners before distribution and exactly what changed between two distributed versions. The only oversight I think in the proposal is staggered distributions so that projects declare a UUID…

> The only oversight I think in the proposal is staggered distributions so that projects declare a UUID and the distribution queue progressively makes it available rather than all or nothing That is indeed an oversight - I wish I had thought of that idea!

No worries. Feel free to popularize it. I’m more worried about supply chain security than credit :).

Re: Dependency cooldowns turn you into a free-rider

#128

Post by duskdozer »

LtWorf wrote: post #106
duskdozer wrote: post #78

Earlier quoted context omitted.

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.

Yes they took money that they have to spend in AI to evaluate the new uploads. Basically they got some free tokens, not actual "money". Also I got a 2 week ban on the python discuss for suggesting that people who contribute on behalf of companies (such as microsoft) should be disclosing it. So PSF is as corporate as it gets in my eyes.

Ah, I didn't realize that was a catch. That changes it a lot. (serious)

Re: Dependency cooldowns turn you into a free-rider

#129

Post by rldjbpin »

The moral judgement of a practice not unknown to those who handle production deployment (takes me back to the days where i had to use a local maven repository with dated dependencies) is on a very shaky foundation.

We used to focus more on finding issues before a new release, and while it remains common to find bugs in older ones, not having enough users should not be used as a crutch for testing.

> (dependency cooldowns) don't address the core issue: publishing and distribution are different things and it's not clear why they have to be coupled together.

Besides some edge cases for a large project, the core issue remains code quality and maintainability practices. The rush to push several patches per day is insane to me, especially in current AI ecosystem.

Breaking changes used to have enough transitionary period, see Python 2 to 3, while today it is done on a whim, even by SaaS folks who should provide better DX for their customers. Regardless, open-source/source-available projects now expect more from their users, and I wonder how much of it remains reasonable.

Re: Dependency cooldowns turn you into a free-rider

#130

Post by vlovich123 »

vlovich123 wrote: post #127
calpaterson wrote: post #23

Earlier quoted context omitted.

> The only oversight I think in the proposal is staggered distributions so that projects declare a UUID and the distribution queue progressively makes it available rather than all or nothing That is indeed an oversight - I wish I had thought of that idea!

No worries. Feel free to popularize it. I’m more worried about supply chain security than credit :).

Also rather than a UUID a hash of the package name is probably sufficient for back compat and avoiding people trying to rotate UUIDs to get sooner / later distribution.
Post reply on HN