• mumblerfish@lemmy.world
      link
      fedilink
      arrow-up
      13
      ·
      8 months ago

      Gentoo just reverted back to the last tar signed by another author than the one seeming responsible for the backdoor. The person has been on the project for years, so one should keep up to date and possibly revert even further back than just from 5.6.*. Gentoo just reverted to 5.4.2.

    • flying_sheep@lemmy.ml
      link
      fedilink
      arrow-up
      9
      arrow-down
      12
      ·
      8 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
          ·
          8 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.

      • corsicanguppy
        link
        fedilink
        arrow-up
        5
        ·
        8 months ago

        when building RPM or DEB.

        Which ones? Everything I run seems to be clear.

        https://access.redhat.com/security/cve/CVE-2024-3094

        Products / Services Components State
        Enterprise Linux 6 xz Not affected
        Enterprise Linux 7 xz Not affected
        Enterprise Linux 8 xz Not affected
        Enterprise Linux 9 xz Not affected

        (and thus all the bug-for-bug clones)

        • progandy@feddit.de
          link
          fedilink
          arrow-up
          3
          ·
          8 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
          ·
          8 months ago

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

        • flying_sheep@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          8 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.