• flying_sheep@lemmy.ml
    link
    fedilink
    arrow-up
    9
    arrow-down
    12
    ·
    7 months ago

    Backdoor only gets inserted when building RPM or DEB. So while updating frequently is a good idea, it won’t change anything for Arch users today.

      • flying_sheep@lemmy.ml
        link
        fedilink
        arrow-up
        13
        ·
        7 months ago

        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.

      • progandy@feddit.de
        link
        fedilink
        arrow-up
        3
        ·
        7 months ago

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

      • Laser@feddit.de
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

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

      • flying_sheep@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        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.