3 ms·

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 thes

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 https://packages.debian.org/bookworm/xz-utils

fullstop 3y ago
> Debian stable (bookworm) has xz-utils version 5.4.1: https://packages.debian.org/bookworm/xz-utils https://packages.debian.org/bookworm/xz-utils Guess who released 5.4.1? JiaT75!
- cassianoleal 3y ago
  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 https://salsa.debian.org/debian/xz-utils/-/tree/v5.4.1/m4
  - fullstop 3y ago
    Neither does https://salsa.debian.org/debian/xz-utils/-/tree/v5.6.0/m4 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.
    - sroussey 3y ago
      Not just commits, but all tarballs released with his key.
    - cassianoleal 3y ago
      > 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 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.
      - seba_dos1 3y ago
        > 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_methods https://wiki.debian.org/PackagingWithGit#Upstream_import_met...).
        cassianoleal 3y ago
        Thanks for the explanation, very helpful!
saalweachter 3y ago
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.

fullstop 3y ago

> Debian stable (bookworm) has xz-utils version 5.4.1: https://packages.debian.org/bookworm/xz-utils https://packages.debian.org/bookworm/xz-utils Guess who released 5.4.1? JiaT75!

cassianoleal 3y ago
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 https://salsa.debian.org/debian/xz-utils/-/tree/v5.4.1/m4
- fullstop 3y ago
  Neither does https://salsa.debian.org/debian/xz-utils/-/tree/v5.6.0/m4 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.
  - sroussey 3y ago
    Not just commits, but all tarballs released with his key.
  - cassianoleal 3y ago
    > 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 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.
    - seba_dos1 3y ago
      > 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_methods https://wiki.debian.org/PackagingWithGit#Upstream_import_met...).
      - cassianoleal 3y ago
        Thanks for the explanation, very helpful!

saalweachter 3y ago

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.