[chowells]

A large portion of the time, the maintainer notices what happened a few hours later. Maybe they were asleep or off doing other things for a while, but they eventually come back. And these kinds of takeovers frequently aren't complete enough to cover their tracks.

So at the very least, adding a cooldown raises the difficulty of these attacks above that threshold.

[nullhole]

> large portion of the time, the maintainer notices what happened a few hours later.

So add it at the package manager level instead of the user level then?

[Barbing]

Would be bad for software/progress I guess but, got me thinking of if we had an expectation a dev would post an update checksum/hash, then follow it up a day later with the update itself...

(well maybe that leads to kidnappings idk)

edit - heh, sibling comment on package manager-level must be much smarter

[latexr]

> Would be bad for software/progress I guess but

We all need to slow down and get some perspective. “Progress” doesn’t mean “rush everything and do it now now now”. Advancements should be slow, methodical, considered. That’s a good thing, not a weakness.

[Barbing]

:)

I like it. Well, it would be tough for everybody whenever a long-awaited feature arrived but was out of touch just behind the glass. Maybe will improve our delayed gratification appreciation!

[bot403]

I fail to see how this isn't a simple cool down with more steps. It doesn't seem to add anything to the security posture of the package/update

[Barbing]

Nobody can expose themselves during the danger period

Dev enforces cooldown on users, not users deciding they want to be safer. Dev has extra step of ensuring they check their accounts every ~23hr indefinitely.

The simple cooldown scenario sees potentially thousands of downloads of a malicious package. The 24 hour developer delay scenario sees zero downloads during the same period.