We all know about the XZ backdoor by now. But there is another
interesting thing that I think we should discuss:
* There was an attempt to sabotage the Landlock sandbox on Linux.
* Capsicum support was outright removed from autotools-based builds.
It seems that the same entity who put the backdoor in XZ has a very high
interest in making sure that the XZ utility runs without a sandbox.
I know this is all speculation, but to me, this is a very strong
indicator that the same entity is sitting on a 0day against XZ that they
would like to use, so they want to get rid of the sandbox before doing so.
Given that they probably also control other projects, just under a
different fake identity, I think it might be a good idea to change all
projects from XZ to either GZ, BZ2 or ZSTD archives. IMO the logical
next thing for the attacker to do would be to create a malicious XZ for
another project that then uses RCE in XZ.
Would there be objections in doing a mass replace of
EXTRACT_SUFX=.tar.xz to EXTRACT_SUFX=.tar.gz/.tar.bz2/.tar.zst?
I cannot see how this would benefit anyone - in general, if your intent is to ensure that the xz library/binary is not installed on a given system, then that couldn't be achieved while any distfile is compressed with the xz algorithm. And, since pkgsrc has no control over how 3rd party software is compressed, and xz is still the most efficient algorithm, I'd see that as not being achievable.
I also think your analysis is flawed - see Filipe Valsorda's analysis of the issue - it's not an auth bypass, but a sophisticated RCE. See also Kevin Beaumont's analysis, which surmises that the execution of the backdoor was accelerated by the move to make more of systemd dependencies into modules, to slim it down, and to reduce the attack surface. Preventing an xz library or binary appearing on a Linux box with pkgsrc wouldn't help this, using a patched or backdoor-predating xz binary would be vastly superior, and not involve any distfile churn. If your SBOM on linux can't distinguish between backdoored and non-backdoored, you've got bigger problems
And then there's the data storage/transfer cost of not using the most efficient compression algorithm
And finally, the poor developer(s) who ends up maintaining xz going forward will now come under excruciating scrutiny, accompanied by aggressive audits of everything that is done. As will other compression methods, and systemd subsystems. Hopefully, systemd itself, too :)