I wrote the original (?) cooldown post that’s linked in this response, and put some thoughts on Cal’s response here [1].
[1]: https://lobste.rs/s/dl4jb6/dependency_cooldowns_turn_you_int...
Dependency cooldowns turn you into a free-rider
91–100 of 131 posts
Re: Dependency cooldowns turn you into a free-rider
#92Earlier 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.
thank you for this example. It's always heartwarming to see such case. However I have this, maybe defeatist, feeling that companies take more than they give - in general. I remember working in companies, where giving away my source code to the public would require a ton of work approval and effort, which was heavily discouraging that. On the other hand, the companies want the opensource to take care of everything...…
I agree with you. I guess that's what people sign up for whether they understand it or not when using licenses like MIT, BSD, etc.
Re: Dependency cooldowns turn you into a free-rider
#93Free-riding is frequently a good strategy. If you don't want other people free-riding on you, sign contracts saying they can't. That means, for instance, don't use MIT license.
Re: Dependency cooldowns turn you into a free-rider
#94> 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…
"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.
Re: Dependency cooldowns turn you into a free-rider
#95I'd rather be free-rider (which I don't buy into the author's thesis), than an unpaid guinea pig.
Re: Dependency cooldowns turn you into a free-rider
#96One of the biggest issues I see with Upload Queues here that is not talked about is the added complexity on the package managers themselves (PyPI, NPM, crates.io ...).
They are already complex beasts of software, extremely important for the ecosystems, and not always well funded. Adding all this extra complexity, with official bypasses (for security reasons), monitoring APIs (for security review while a new version is in the queue), and others is not cheap.
And if somehow, they get the funding to do this, will they also get the funding for the maintenance in the long term?
I don't think the benefits here (which is only explicitly model the cooldown) are enough to offset the downsides.
Re: Dependency cooldowns turn you into a free-rider
#97Earlier 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.
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!
Re: Dependency cooldowns turn you into a free-rider
#98A 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.
> One problem of the central cooldown is that it restricts the choice to be able to consume a package immediately
Huh? The article specifically suggests there could be an opt-in to early releases, and that the published revisions are available (e.g. for researchers) just not distributed by default.
Re: Dependency cooldowns turn you into a free-rider
#99My company implements cooldowns by never updating anything ever. (Send help)
Re: Dependency cooldowns turn you into a free-rider
#100[flagged]