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.
The central repository tukaani-project/xz on GitHub has now been disabled by GitHub with the message:
The ToS violation presumably due to the compromised upstream commit access. In any event, a notable step given today's slurry of news albeit in the disabled state makes it more difficult to track down other potentially problematic changes by the bad actor(s) with access to merge request data and other pertinent information blocked.
With upstream XZ having not issued any corrected release yet and contributions by one of its core contributors -- and release creators -- over the past two years called into question, it's not without cause to outright taking the hammer to the XZ repository public access. At this point, it can simply not be trusted until further evaluation.
Some such as within Fedora discussions have raised the prospects whether XZ should be forked albeit there still is the matter of auditing past commits. Others like Debian have considered pulling back to the latest release prior to the bad actor and then just patching vetted security fixes on top. Meanwhile others have suggested this is good motivation for moving off XZ/liblzma to alternatives such as using Zstd.
The central repository tukaani-project/xz on GitHub has now been disabled by GitHub with the message:
"Access to this repository has been disabled by GitHub Staff due to a violation of GitHub's terms of service. If you are the owner of the repository, you may reach out to GitHub Support for more information."
The ToS violation presumably due to the compromised upstream commit access. In any event, a notable step given today's slurry of news albeit in the disabled state makes it more difficult to track down other potentially problematic changes by the bad actor(s) with access to merge request data and other pertinent information blocked.
With upstream XZ having not issued any corrected release yet and contributions by one of its core contributors -- and release creators -- over the past two years called into question, it's not without cause to outright taking the hammer to the XZ repository public access. At this point, it can simply not be trusted until further evaluation.
Some such as within Fedora discussions have raised the prospects whether XZ should be forked albeit there still is the matter of auditing past commits. Others like Debian have considered pulling back to the latest release prior to the bad actor and then just patching vetted security fixes on top. Meanwhile others have suggested this is good motivation for moving off XZ/liblzma to alternatives such as using Zstd.
142 Comments