Right, the systemd notification framework is very simple and I've used it in my projects. I didn't even know that libsystemd provided an implementation.

My Arch system was not vulnerable because openssh was not linked to xz.

IMO every single commit from JiaT75 should be reviewed and maybe even rolled back, as they have obliterated their trust.

edit:

https://github.com/google/oss-fuzz/pull/10667

Even this might be nefarious.

> the systemd notification framework is very simple and I've used it in my projects

Have you come across an outline or graph of systemd that you really like, or maybe a good example of a minimal setup?

If they hadn't been modifying SSH their users would never have been hit by this backdoor. Of course if it is actually intended to target SSH on Debian systems, the attacker would likely have picked a different dependency. But adding dependencies like Debian did here means that those dependencies aren't getting reviewed by the original authors. For security-critical software like OpenSSH such unaudited dependencies are prime targets for attacks like this.

My point was, this is not "Debian did a thing". Lots of other distros do the same thing. In this particular case, it was in fact fortunate for users of all these other distros that Debian did it, lest this vulnerability might have never been found!

Also, only users on sid (unstable) and maybe testing seem to have been affected. I doubt there are many Debian servers out there running sid.

Debian stable (bookworm) has xz-utils version 5.4.1: https://packages.debian.org/bookworm/xz-utils

> Debian stable (bookworm) has xz-utils version 5.4.1: https://packages.debian.org/bookworm/xz-utils

Guess who released 5.4.1? JiaT75!

5.4.1 doesn't even have the `m4/build-to-host.m4` script that pulls the backdoor's tarball.

https://salsa.debian.org/debian/xz-utils/-/tree/v5.4.1/m4

Neither does https://salsa.debian.org/debian/xz-utils/-/tree/v5.6.0/m4

The script was not present in the git tree, only in the released archives.

I'm also suggesting that there could be more than one exploit present. All of their commits should be rolled back, none of it can be trusted.

> The script was not present in the git tree, only in the released archives.

I confess I couldn't quite figure out the branching and tagging strategy on that repo. Very weird stuff. That script seems to have been added by Sebastian Andrzej Siewior just ahead of the 5.6.0 release. It's definitely present in the Debian git tree, and probably in many other distros since others seem to be affected.

The commit where the script was added to Debian is tagged `upstream/v5.6.0` despite the script itself not being present on that tag upstream: https://github.com/tukaani-project/xz/tree/v5.6.0/m4

> I'm also suggesting that there could be more than one exploit present. All of their commits should be rolled back, none of it can be trusted.

I agree.

> I confess I couldn't quite figure out the branching and tagging strategy on that repo.

It's just a regular Debian packaging repository, which includes imports of upstream tarballs - nothing out of ordinary there. Debian packaging is based on tarballs, not on git repos (although in absence of upstream tarballs, Debian maintainer may create a tarball out of VCS repo themselves).

The linked repo just happens to include some tags from upstream repo, but those tags are irrelevant to the packaging. Only "debian/*" and "upstream/*" tags are relevant. Upstream VCS history is only imported for the convenience of the packager, it doesn't have to be there.

Debian's git repositories don't have any forced layout (they don't even have to exist or be up-to-date, the Debian Archive is the only source of truth - note how this repo doesn't contain the latest version of the package), but in practice most of them follow the conventions of DEP-14 implemented by gbp (in this particular case, it looks like `gbp import-orig --upstream-vcs-tag`: https://wiki.debian.org/PackagingWithGit#Upstream_import_met...).

Thanks for the explanation, very helpful!

Not just commits, but all tarballs released with his key.

I would phrase it as "It's good we have a heterogenous open-source community".

Monocrops are more vulnerable to disease because the same (biological) exploit works on the entire population. In our Linux biosphere where there are dozens of major, varied configurations sharing parts but not all of their code (and hundreds or thousands of minor variations), a given exploit is likely to fail somewhere, and that failure is likely to create a bug that someone can notice.

It's not foolproof, but it helps keep the ecosystem healthy.

It takes a village.