That’s the main question.
There are plenty of tools to bombard code that analyze common red flag patterns + AI tools to do the same…but still it begs for manual checks before pushing anything.
A motivated bad actor can have more than 1 trusted user, and can approve it’s own bad code…
I guess only automation pre-checks + manual reviewers (preferably at least 10 regular trusted ones should evaluate every commit) which is not trivial task.
Another malicious commit was found
Just to satisfy my paranoia, as I was just about to install on a new laptop: The EndeavourOS_Galileo-Neo-2024.01.25.iso predates the backdoor, and installing with that will put the post-backdoor-fix version on the target system?
If you do an online install, you will get the latest no-backdoor-ed version automatically.
If you do an offline install followed by an upgrade, you will land on the latest no-backdoor-ed version as well.
Oh I just noticed your new avatar!
Is it out of support for xz developers or just funny timing?! 
Just to 
the LinuXZ community.
Edit: sorry, forgot the credits: https://infosec.exchange/@fr0gger/112189232773640259
Hi guys!
I saw this thread today, and since both of my machines had Version 5.6.1-1 I updated both and removed the old versions from paccache.
Then I reread the thread and also read the thread over at the arch forums. Unfortunately, most of this stuff is way beyond my technical knowledge. So I would like to recapitulate here how I understood what I read, pls correct me if I’m wrong:
There is a backdoor in specific versions of xz. But although those versions have been used in Arch we are not sure if those actually indeed contained the backdoor
Referring to this:
“By disassembling the liblzma library (which is the affected part, as far as I’ve understood), it appears that our packages might have never been affected by the backdoor, due to a deb/rpm check in the script that decides whether to inject the vulnerability or not.”
But even when the backdoor was indeed present it couldn’t have been used/exploited
Referring to this:
“Arch does not directly link openssh to liblzma, and thus this attack vector is not possible.”
So, not really an issue for Arch, correct?
But there could be more and it looks like there are hints that there is more. The Arch thread mentions something about a disabled sandbox. I think this hasn’t been mentioned here so far, can anyone explain pls?
Referring to this:
" Upgrade to the 5.6.1-2 release, which doesn’t have the SSH backdoor, but does disable the landlock sandbox and possibly more."
Correct.
Possibly, though probably unlikely.
A Micro- $oft/saft/shaft/shift/shoft/whatever engineer caught Ze Bug!!
Micro- $oft/saft/shaft/shift/shoft/whatever loves LinuXZ!
I love it!
Will your next avatar be Ze Bug
Don’t give me ideas …
I guess if you’re in the loop of Micro$tuff software development, you’re in a good position to know that you’d much better use anything else. (to the point where you even feel the urge to report any problem on your favorite OS)
thanks for the finding that. I often do need the seasame st. version vs tech articles 
.
I read that if you have Micro- $oft/saft/shaft/shift/shoft/whatever’s Wind- oze/-blows/-woes/whatever installed in dualboot with Linux, it can compromise your system by injecting #%@!ware into your Linux kernel.
It’s just “funny” how they could pass on this one, a Golden opportunity discovered by Micro- $oft/saft/shaft/shift/shoft/whatever’s principal software engineer.
His job may be hanging on very thin thread
…or maybe his was part of a greater one:
It’s never pleasant when it’s not YOUR backdoor I guess
But otherwise, where did you see about the dual boot stuff ?
(Even if I assume the “needed” backdoors are probably already in place everywhere at the hardware level anyway…)
I would venture to say that they have enough resources to be able to exploit it 
Seek, and ye shall find --Matthew 7:7
It’s much closer than you think 
never will I use the trite and cliched ‘Windoze’ when referring to the dark star. For now on it’s Microshaft.
I take back the thumbs up I gave you and will now replace it with a Gold Medal:)
By rebuilding the entire codebase against a known uncompromised version of the XZ library, openSUSE aims to safeguard its users against potential breaches and maintain the trustworthiness of its distribution.
If you use this fantastic rolling-release distribution, you’ll be amazed that around 2000 updates are ready for you today. That’s correct – openSUSE Tumbleweed has rebuilt its whole codebase and every package.
https://linuxiac.com/tumbleweed-users-face-urgent-2000-package-updates/
The following 29 patterns are going to be upgraded:
apparmor base basesystem documentation enhanced_base fonts fonts_opt gnome_basic gnome_basis gnome_basis_opt gnome_games gnome_imaging gnome_internet gnome_multimedia gnome_office gnome_utilities gnome_yast imaging laptop minimal_base
multimedia office sw_management x11 x11_enhanced x11_yast x86_64_v3 yast2_basis yast2_desktop
The following product is going to be upgraded:
openSUSE Tumbleweed 20240326-0 -> 20240329-0
The following NEW package is going to be installed:
kernel-default-6.8.1-1.2
The following package is going to be REMOVED:
kernel-default-6.8.1-1.1
The following package requires a system reboot:
kernel-default-6.8.1-1.2
2098 packages to upgrade, 1 new, 1 to remove.
Overall download size: 1.67 GiB. Already cached: 0 B. After the operation, additional 2.4 MiB will be used.
Note: System reboot required.
Now that’s commitment. Kudos to the OpenSUSE team.