Hacker News Reader

Comment by reisse | Hacker News Reader

> EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page.

Why? Isn't it better to freeze them and let as many people as possible analyze the code?

Good question, though I can imagine they took this action for two reasons:

1. They don't have the ability to freeze repos (i.e. would require some engineering effort to implement it), as I've never seen them do that before.

2. Many distros (and I assume many enterprises) were still linking to the GitHub releases to source the infected tarballs for building. Disabling the repo prevents that.

The infected tarballs and repo are still available elsewhere for researchers to find, too.

They could always archive it. Theoretically (and I mean theoretically only), there's another reason for Microsoft to prevent access to repo: if a nation state was involved, and there've been backdoor conversations to obfuscate the trail.

Archiving the repo doesn't stop the downloads. They would need to rename it in order to prevent distro CI/CD from keeping downloading untrustworthy stuff.

Distros downloading directly from GitHub deserve what they get.

Maybe one can get the code from here. New commits being added it seems.

https://git.tukaani.org/

The latest commit is interesting (f9cf4c05edd14, "Fix sabotaged Landlock sandbox check").

It looks like one of Jia Tan's commits (328c52da8a2) added a stray "." character to a piece of C code that was part of a check for sandboxing support, which I guess would cause the code to fail to compile, causing the check to fail, causing the sandboxing to be disabled.

Lasse has also started his own documentation on the incident.

https://tukaani.org/xz-backdoor/

Shouldn't they have tests running to ensure that the check works on at least some systems?

What do you mean "tests"?

Have a system were you wxpect the sandboxing to work and have an automated check that it compiles there?

Part of the backdoor was in the tests. The attacker in this case could easily have sabotaged the test as well if a test was required.

If your project becomes complex enough eventually you need tests for the configure step. Even without malicious actors its easy to miss that a compiler or system change broke some check.

You can still find the source everywhere, if you look for it. Having a fine-looking page distribute vulnerable source code is a much bigger threat.

You can find it on archive. Someone archived it last night

Reply on news.ycombinator.com