Hacker News new | ask | show | jobs
by captn3m0 20 hours ago
Author here - people are definitely looking at other places. This just happens to be where the attacks are, and gets disproportionate attention as a result.

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.

2 comments

People are disregarding model where registry is responsible for what they publish.

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.

I haven't ever seen "a campaign" get through Debian's release process, besides xz-utils.

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.

This piqued my curiosity and it seems you really didn't do it justice there. Rather than patch out the actual use of the uninitialized memory (always a good thing to do) IIUC instead the core part of the function that mixes new randomness in was patched out. Like the tire was flat so you went ahead and just chopped off the entire axle with an angle grinder because who needs 4 wheels anyway.
Agreed, but you also have to look at it from a packager's point of view. Here is the actual patch: https://salsa.debian.org/debian/openssl/-/commit/8f27a7dc022...

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)

A community that thought it knew better than upstream, and didn't check their changes with them.

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.