ui2RjUen875bfFA

i guess the big opensource community should put a little bit more trust in statistics or integrate statistic evaluation in their decission making to use specific products in their supply chains.

there are some researches on the right track already https://www.se.cs.uni-saarland.de/projects/congruence/

i added there something about a possible planned kernel attack which not mentioned so much yet.

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...

> Arch Linux played an important role in making this compression software trusted and depended upon.

because of the way arch distributes packages? then what you think about freebsd?

You might read https://www.openwall.com/lists/oss-security/2024/03/29/4

"However, building from source wouldn’t have protected you against this specific backdoor." Depends on how exactly you build from source. A generic build was not the target. Andres Freund showed that the attack was targeted against a specific type of build system.

just take a closer look at the analysis https://www.openwall.com/lists/oss-security/2024/03/29/4

then try to understand the pattern. they backdoored by modifying the build process of packages. now consider the $XZ is also from a backdoored build and the call recognizes in the same way with parameters --robot --version and the shell environment with the hint "xz_wrap.sh" from the piped process. a lot stuff to recognize for the $XZ process that it run as part of a kernel build.

Maybe they put advanced stuff in a backdoored $XZ binary to modify the kernel in a similar way they modified lzma based packages in the build process.

those pipe usages are quite suspicious

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...

pipeing into this shell script which now uses "eval"

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...

i guess this will be revisited and removed soon