[weinzierl]

If this is the idea, why don't we let the dedicated security firms and/or automated scanners find the vulnerabilities before the release?

You need an early release in the "given enough eyeballs all bugs are shallow" world because you need the eyeballs, but if you count on specialists and scanners no general availability release is necessary and hence no cool down.

[nixpulvis]

Because this isn't about guarding against general vulnerabilities. This is about guarding against a class of supply chain attack where an attacker compromises the packaging system in a way that they slip in a malicious release.

It is true if everyone waits a cooldown (I don't like this name, but that's another thing) period, then it doesn't solve anything, but as others have pointed out, just because you don't build off the cooldown doesn't mean you and others aren't watching the releases.

Closing the window makes the burden of hiding the exploit higher, which is I think objectively an improvement of security posture.

[john_strinlai]

i am not sure what the benefits of your proposal are compared to the "cooldown period" way.

the releases will be delayed for the same time period, but you increase the amount of coordination required significantly and reduce user agency.

[weinzierl]

Currently we release software to the public early and let people find vulnerabilities after release. A few early updaters get burned but the rest of us is saved. This cannot go on.

One idea to get out of this mess is to use cooldowns. But this idea only works if what GP said is true: Vulnerabilities are mostly found by (paid) specialists and advanced tools and not the general user populations.

My point is that, if that is true we do not need to release insecure software. Do the magic before the release and no one gets hurt.

[AgentME]

We could rename "cooldown" to "pre-release period".

[zem]

the we/you are different in each case. say I maintain some package, foo, and I want to publish foo-3.5 which contains a security issue. in the cooldown scenario I push the new version to the package repository (rubygems/pip/npm/whatever), and the package manager when asked to `install foo` continues reporting 3.4 as the latest version until the cooldown period has passed. this happens automatically for all packages and all end users. simultaneously, a security firm could look at the log of new package submissions and take a closer look at anything that triggers their "this is an important/widely used package" filter, and if they find something during the cooldown period the new release could be removed from the repository without anyone having installed it.

in the "find the vulnerability before release" scenario, how do I push version foo-3.5? is it my responsibility as the package author to find a security firm and have them audit it before submitting to the repository? should the org owning the repository shunt my package update to a holding pen until it can be vetted, and if so do they have to pay a designated security firm and give them special access to the holding pen, or can anyone reads the incoming packages and help vet them? and if no one has looked at a package in a while do you delay it indefinitely or so you let it time out and be released? that's basically back to the cooldown idea, only implemented on the server rather than the client, and therefore not letting individual clients tune what they believe is a good cooldown time.