GitHub Disables The XZ Repository Following Today's Malicious Disclosure

[phoronix]

Phoronix: GitHub Disables The XZ Repository Following Today's Malicious Disclosure

Today's disclosure of XZ upstream release packages containing malicious code to compromise remote SSH access has certainly been an Easter weekend surprise... The situation only looks more bleak over time with how the upstream project was compromised while now the latest twist is GitHub disabling the XZ repository in its entirety...

https://www.phoronix.com/news/GitHub-Disables-XZ-Repo

[emansom]

Good call to not trust any code of the developer and/or xz itself until further investigation. Bad call to disable all access, it was a central point to discuss. Welp, guess there's Hacker News still.

[mirmirmir]

Usual devious aah CIA tomfoolery or Facebook tomfoolery? I can't decide

[Barley9432]

Good call to not trust any code of the developer and/or xz itself until further investigation. Bad call to disable all access, it was a central point to discuss. Welp, guess there's Hacker News still.

Central point to discuss what? All I saw there was speculation or nonsense.

[roviq]

Hmm, I really like Zstd for things like filesystem/stream/on-the-fly compression (I use it with btrfs and zfs), but XZ, 7zip, and related LZMA-family really does a great work squeezing bytes, and very useful for long term archival and other scenarios.

Apropos, I remember this post from the lzip maintainers about xz: https://www.nongnu.org/lzip/xz_inadequate.html

[gbcox]

Yeah, I've already started changing my scripts away from xz. Anyway, the way this whole thing has unfolded is just bizarre. Too many Manchurian Candidate vibes for me. At this point I don't see a compelling reason to stick with xz since there are a number of excellent alternatives.

[curfew]

Good call to not trust any code of the developer and/or xz itself until further investigation. Bad call to disable all access, it was a central point to discuss. Welp, guess there's Hacker News still.

They violated GitHub terms of service, end of story.

[Chugworth]

Until now I wasn't too familiar with XZ. I would think that most system tasks involving compression should just move to Zstd, and if you want to use LZMA for archival then just use 7zip. Personally I've always preferred RAR over 7zip, but these days I don't really use either for archival. The built-in compression and error correction in ZFS is adequate for me, and gives direct access to the file itself. Snapshots allow me to confirm whether or not there have been any changes to the file. For datasets intended for archival, I crank the compression level up to 19. That does make it slower and use more CPU, but that doesn't really matter if I rarely access that dataset.

[CommunityMember]

Hmm, I really like Zstd for things like filesystem/stream/on-the-fly compression (I use it with btrfs and zfs), but XZ, 7zip, and related LZMA-family really does a great work squeezing bytes, and very useful for long term archival and other scenarios.

Moving to zstd as the new standard compression choice may be a good plan, but the reality is that there exists many existing (and there will be newly created by existing workflows) files in xz/lzma such that xz will need to be supported for quite some time (essentially forever).

[cend]

A mirror is still active for anyone to audit:

https://git.tukaani.org/?p=xz.git;a=tree