This is extremely suspicious.

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.

Also interesting, to me, how the GMail account for the backdoor contributor ONLY appears in the context of "XZ" discussions. Google their email address. Suggests a kind of focus, to me, and a lack of reality / genuineness.

This also means that Google might know who they are, unless they were careful to hide behind VPN or other such means.

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

> pipeing into this shell script which now uses "eval"

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.

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.

because in order to put backdoor into xz executable, you need to infect its sources. and in order to infect the sources, you need to use a similar technique to hide the modification

"started to cc himself" seems to be simply "contributing to a new project and not having git-send-email fully set up". By default git-send-email Cc the sender, though in practice it's one of the first options one changes.