Funny how Lasse Collin started to ccing himself and Jia Tan from 2024-03-20 (that was a day of tons of xz kernel patches), he never did that before. :)
https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...
https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...
It looks like someone may have noticed a unmaintained or lightly maintained project related to various things, and moved to take control of it.
Otherwhere in the discussion here someone mentions the domain details changed; if you have control of the domain you have control of all emails associated with it.
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
I don’t actually see an issue with that `eval`. Why would one consider running `xz` followed by `eval`-ing its output more insecure than just running `xz`? If `xz` wants to do shenanigans with the privileges it already has, then it wouldn’t need `eval`’s help for that.
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.