so in the fallout of the XZ issue we are looking at using liblzma (and XZ) as little as possible in the OS (due to the “how much can we trust” issue). One place where this rubs a bit is in rpm (and rpm2cpio specifially). RPM has supported (and for us at least, defaulted) to using zstd for some time now, but are still RPM files out there that are XZ compressed. The one we know about is the official Google Chrome browser RPM.
So on the one hand we’d like to not use xz/liblzma for RPM, but on the other hand it might impact folks who use rpm2cpio to install the Chrome browser…
So two questions
Is anyone using the Chrome browser this way
What would you do if you were us? Take out xz/liblzma for peace of mind, or keep compatibility with the Google Chrome RPMs
(and we sure hope Google changes their compression away from XZ… even zlib would be better at this point)
I use Google Chrome, installed via rpm2cpio. I also have Chromium Browser installed similarly. Ditto, VSCodium installed via rpm.
Bah… This is horrible. I’m at a cross point with Clear Linux.
Recent GNOME 46 (gnome-terminal specifically) does not work reliably on Xorg. Terminal input has 1 second lapse, randomly. This caused me to rolled back to 41270.
The NVIDIA driver has not reached reliability on Wayland (particularly Xwayland). Supposedly, that may not happen until NVIDIA releases version 555.
Now this xz problem.
Checking to see how much further to roll back for older xz 5.4.y e.g. Clear 41210. The problem is that there were many broken Clear releases and unsure which one to roll back to. This is until the NVIDIA 555 driver. Perhaps Wayland/Xwayland will work better.
I guess everyone has their own use cases. For mine, it would be no issue to get rid of it at all.
Also, I think it (XZ) will disappear in no time anyway. Look how fast X11 is disappearing everywhere
I can just say, that ClearLinux did not cause any of these issues you mentioned.
For Google Chrome and VSCode… Did you consider Flatpak?
Question for the Clear team - as I understand it, the vulnerability was introduced in the tarball and not the Git repo. Do we pull from the repo or from the tarball?
so we have/had a policy of using the tarbal not the git tar, because the tarbal was cryptographically signed by “the maintainer” and we automatically verify the signatures etc…
(now of course the problem was … the official (but new) maintainer)
so yeah you can assume we’ll go analyze if we need to change our policy here