Do you have examples of campaigns that weren’t flagged? Everything except xz had a 1 day window and Dependency Cooldowns are super effective against most campaigns for that reason.
See papers at https://kokkonisd.github.io/ for eg.
Do you have examples of campaigns that weren’t flagged? Everything except xz had a 1 day window and Dependency Cooldowns are super effective against most campaigns for that reason.
See papers at https://kokkonisd.github.io/ for eg.
Your solution does exactly that. Giving hooks to end users just pushes the responsibility to the users.
Yes all issues were publicized and marked in hours. Sorry but hours is not good enough when there is countless CI pipelines running in a single hour.
Only solution is not allowing to publish malicious stuff. Cooldowns are also not the solution because possibilities to publish malicious code is still there if no one reviews it.
The only major blemish in Debian's record was in 2006 when one of its developers patched OpenSSL to avoid using uninitialised memory as a source of randomness, in order to placate a static analyser. Nobody in Debian noticed that this effectively made OpenSSL key generation entirely predictable (it only generated one of 32768 unique keys), for 2 years.
Notice how clean and small a patch it is? (ignore that, in making it clean and small, it has "chopped off the entire axle" as you say)
And here's what led to making that patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
These links contain specific people's names, but the important thing is not to blame those people specifically, because this failure came from the whole Debian community and its values. A community that eagerly went looking for, e.g. valgrind correctness. A community that thought it knew better than upstream, and didn't check their changes with them. A community that values neat patches that close bugs, without thinking of the wider ramifications.
The community has learnt a lot of lessons since 2008, and is now much more aware of how packager meddling could cause security flaws.
(You could also single out the OpenSSL developers for their faults too, but this particular error was on Debian)
It is my recollection that they both tried to run it by upstream, and believed that they had successfully done so. That may still be an error, but not the kind of fundamental flaw you imply.
That is not fair. Debian generally works close with upstream, since most Debian Developers are free software enthusiasts in some way. The patch in question made it to the OpenSSL mailing list and received only encouragement. The only problem, as it turns out, was that less than a handful people knew those parts of OpenSSL well enough, and they didn't have time to hang around the mailing list. The real development of OpenSSL happened behind closed doors.
A lot of people learned from that incident. It is wrong to blame it on the Debian Developer who tried to clean up the code and went to the OpenSSL development mailing list for help. It is far from clear that uninitialized memory helps randomness at all, unless you are intimately familiar with the history behind those lines.