https://www.openwall.com/lists/oss-security/2024/03/29/4
GitHub is disabled, the package has to be reverted before 5.6.0
xz/liblzma is compromised
- Edited
No, there is no consensus yet on when this started.
xz was already rebuild to mitigate the known issue (release manager created tarball contains code with a backdoor), github automatically created source tar does not contain it. Thus xz was rebuild from github source.
See commit from yesterday:
https://github.com/KaOSx/core/commit/ef3e86b6f8dbb4c78aade33d28f36bb5f9c9a2de
Tests had already been run if either xz package (in core or build) are effected by known backdoor, neither is.
But, not listed in the security link above is the fear that this malicious code injection has been going on much longer, so there is no use in going back to any other version. Another point, so far only deb & rpm can be effected by known backdoor, and distros that are doing a lot of linking with lzma, neither is the case in KaOS.
- Edited
A good timeline reference:
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Discussion:
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
- Edited
Full git is luckily still up (and one commit by the original dev):
https://git.tukaani.org/?p=xz.git;a=summary
And a statement from that same original dev:
https://tukaani.org/xz-backdoor/
I like that writeup from a long time open source contributor, on how to prevent these issues from happening. https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/
Actually, I got full access to entire KDE infra after 2 patches in 2015, it's normal contributors to be welcomed, but to become maintainer (to sign executable and make release) should be conservative.
Another reason why projects like kup should do releases, instead of committing to git only and leaving it at that.