No, read the link you posted:

Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:

ldd "$(command -v sshd)"

However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way.

I think that was a precaution. The malicious build script ran during the build, but the backdoor itself was most likely not included in the resuling package as it checked for specific packaging systems.

https://www.openwall.com/lists/oss-security/2024/03/29/22

Those getting the most recent software versions, so nothing that should be running in a server.

Fedora 41, Fedora Rawhide, Debian Sid are the currently known affected ones AFAIK.

I think it needs to be

• rolling release (because it was caught so quickly that it hasn’t made its way into any cadence based distro yet)
• using the upstream Makefile task to build a RPM or DEB (because the compromised build script directly checks for that and therefore doesn’t trigger for a destdir build like Gentoo’s or Arch’s)
• using the upstream provided tarball as opposed to the one GitHub provides, or a git clone (because only that contains the compromised Makefile, running autotools yourself is safe)

Points 1 and 2 mean that only rolling release RPM and DEB distros like Debian Sid and Fedora are candidates. I didn’t check if they use the Makefile and the compromised tarballs.