I don’t agree with all the doom saying about XZ incident.

You just know orgs are going to return after Easter and panic about it unnecessarily (they’re likely still on Redhat 6). It doesn’t impact them as it was caught super early.

Regarding the narrative that there’s nothing that can be done about these type of attacks - I also don’t agree. There’s already a change in the pipeline to systemd which would have prevented it.

The thing needs rational, calm reaction and response.

Before anybody points it out, I know I am in the wrong industry if I want rational calm response - LinkedIn in still full of people saying the boat got ‘cyber attacked’, and governments are busy trying to solve supply chain risks by banning HUAWEI.

The industry is basically powered by people running into a crowded theatre and shouting CYBER. Then when people point out there’s no cyber, they’re like ‘yes.. but there COULD be cyber’. Thanks, very helpful.

For those asking what systemd change, easy write up: https://github.com/systemd/systemd/issues/32028

It was in train before the XZ issue was discovered, which may be why the threat actor sped up, started making mistakes and started begging distros to upgrade XZ - as what looks to be years of planning was about to be flushed down the pan.

Reduce dependencies of libsystemd · Issue #32028 · systemd/systemd

Component systemd Is your feature request related to a problem? Please describe The recent sshd/xz backdoor fiasco (CVE-2024-3094) has shown that the extra dependencies introduced by libsystemd may...

GitHub
@GossiTheDog That change will never happen, though - systemd has been a spaghetti ball of interconnected code with no architectural boundaries since the very beginning, and they have *never* even accepted that doing it like that is a fundamental design problem, let alone consider any changes that would make the ball a bit more modular and potentially splittable into components. They're going to hide some things behind dlopen and call it a day.