Hacker News Reader

Comment by grncdr | Hacker News Reader

I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.

View on HN

Yep, this is the thesis behind them. I wish people engaged more fully with this argument: it’s possible to believe that security vendors won’t do a good job of upholding their side of the bargain, but I’ve yet to see anybody argue that rather than making a faulty universalization argument against cooldowns.

Anything that isn't blatantly obvious zero effort malware is gonna wait for the cooldown to expire and then gradually introduce backdoors or vulnerabilities in subsequent versions once the project has gained trust.

I think you’re talking about something different than the median case here: the kinds of malware that cooldowns are effective against are attacking already trusted projects, e.g. via repository compromise.

I think it remains to be seen whether the economics of this kind of “supply chain” compromise support a stealthier actor profile: the whole reason to compromise an OSS project rather than exploit a single victim’s browser or phone is to smash-and-grab en masse. That’s a fundamentally noisy and delay-sensitive attacker profile.

How many people are paying security firms to test these things during the cooldown period? Which security firms are testing which packages?

> How many people are paying security firms to test these things during the cooldown period?

More than I think should be, frankly. More than enough for a sustainable industry.

As for “which firms”: if you Google any of the recent dependency compromises, you’ll see their names. My rough guess is that there are somewhere between 12 and 20 active players in the “supply chain security” space, and they generally compete for mindshare with blogspam. That’s not to say their scanning results aren’t good, though.

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.

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.

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.

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

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.

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.

Reply on news.ycombinator.com