5 ms·

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

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/ https://kokkonisd.github.io/ for eg.

ozim 3mo ago
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.
amiga386 3mo ago
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.
- fc417fc802 3mo ago
  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.
  - amiga386 3mo ago
    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/8f27a7dc022e95ab7274628715f22207235f8e36 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 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)
    - yjftsjthsd-h 3mo ago
      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.
    - xorcist 3mo ago
      > thought it knew better than upstream, and didn't check their changes with them 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.

ozim 3mo ago

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.

amiga386 3mo ago

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.

fc417fc802 3mo ago
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.
- amiga386 3mo ago
  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/8f27a7dc022e95ab7274628715f22207235f8e36 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 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)
  - yjftsjthsd-h 3mo ago
    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.
  - xorcist 3mo ago
    > thought it knew better than upstream, and didn't check their changes with them 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.