> 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.