[Discuss] Debian 12 in the Cloud

[markw at mohawksoft.com]

> And this is all entirely irrelevant to the XZ supply chain attack,
> because the backdoor isn't in the source code. It's in the test
> harness. If you used 'git clone' then you would never see it because
> the payload was excluded by the .gitignore file. You had to use the
> tarball, and you had to build under specific conditions, for the
> payload to be injected into the source at build time.

This is exactly right. The xz code was identified as something that could
be attacked. This wasn't script kiddies finding a vulnerability, the was a
concerted attack on infrastructure. They didn't FIND a vulnerability, they
CREATED it. I don't believe that it is a systemd thing at all but a new
strategy of which we all have to be aware for all of our projects.

When you fork() and execute code, what is in your process space that can
be capitalized upon? What is in all those seemingly trusted thirdparty
libraries we use all the time?

Like it or not, computers are far far bigger and more complex. It is
almost impossible to know everything that they are doing. They are no
longer embedded devices with 4K proms and 256 bytes of RAM, today,
computers are bigger than anything we ever could have accessed 20 years
ago. Just writing email, my computer has 658 processes running and doing
stuff. I can track down what each is doing, sure. Then I would need to
download all the source code and inspect all that. Then I would need to
inspect the build system. Then I would need to inspect and try to follow
the M4 nonsense. See what I'm saying? No one knows it all. That's how the
xz vulnerability was created.




> --
> \m/ (--) \m/
> _______________________________________________
> Discuss mailing list
> Discuss at driftwood.blu.org
> https://driftwood.blu.org/mailman/listinfo/discuss
>