Better for the cool down to be managed guaranteed centrally by the package forge rather than ad-hoc by each individual client.
Better for the cool down to be managed guaranteed centrally by the package forge rather than ad-hoc by each individual client.
The cooldown is a defence against malicious actors compromising the release infrastructure.
Having the forge control it half-defeats the point; the attackers who gained permission to push a malicious release, might well have also gained permission to mark it as "urgent security hotfix, install immediately 0 cooldown".
I have not heard anyone seriously discuss that cooldown prevents compromise of the forge itself. It’s a concern but not the pressing concern today.
And no, however compromised packages to the forge happens, that is not the same thing as marking “urgent security hotfix” which would require manual approval from the forge maintainers, not an automated process. The only automated process would be a blackout period where automated scanners try to find issues and a cool off period where the release gets progressively to 100% of all projects that depend on it over the course of a few days or a week.
That’s tricky, sometimes you really need the new version to be available right away.
There’s ways to handle that. But that’s the exception, not the rule.
foobarizer>=1.2.3 vs foobarizer==1.2.5