Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by junon on Saturday March 30, 2024 @08:22AM
(#39874159)
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.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by nihilanth on Saturday March 30, 2024 @08:54AM
(#39874389)
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.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by jarfil on Saturday March 30, 2024 @03:11PM
(#39877690)
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.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by account42 on Tuesday April 02, 2024 @07:26AM
(#39904508)
Distros downloading directly from GitHub deserve what they get.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by Sebb767 on Saturday March 30, 2024 @08:21AM
(#39874150)
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.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by AtNightWeCode on Saturday March 30, 2024 @09:18AM
(#39874587)
Maybe one can get the code from here. New commits being added it seems.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by ptx on Saturday March 30, 2024 @12:04PM
(#39876115)
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.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by junon on Saturday March 30, 2024 @12:53PM
(#39876466)
Lasse has also started his own documentation on the incident.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by josefx on Saturday March 30, 2024 @04:28PM
(#39878307)
Shouldn't they have tests running to ensure that the check works on at least some systems?
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by windenntw on Sunday March 31, 2024 @06:30AM
(#39883011)
What do you mean "tests"?
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by josefx on Monday April 01, 2024 @09:25AM
(#39893948)
Have a system were you wxpect the sandboxing to work and have an automated check that it compiles there?
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by ptx on Tuesday April 02, 2024 @07:42AM
(#39904607)
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.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by account42 on Tuesday April 02, 2024 @07:34AM
(#39904555)
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.
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by megous on Saturday March 30, 2024 @11:11AM
(#39875583)
Yeah, another of the reasons not to host anything on Github but optional git mirrors, if you don't want your FOSS project to be subject to Microsoft playing a "world police".
Re:Backdoor in upstream xz/liblzma leading to SSH server com...
by junon on Saturday March 30, 2024 @12:23PM
(#39876261)
Don't agree here. I've only ever seen GitHub do this in extreme circumstances where they were absolutely warranted.
Why? Isn't it better to freeze them and let as many people as possible analyze the code?