• fl42v@lemmy.ml
    link
    fedilink
    arrow-up
    18
    ·
    6 months ago

    Incorrect: the backdoored version was originally discovered by a Debian sid user on their system, and it presumably worked. On arch it’s questionable since they don’t link sshd with liblzma (although some say some kind of a cross-contamination may be possible via a patch used to support some systemd thingy, and systemd uses liblzma). Also, probably the rolling opensuse, and mb Ubuntu. Also nixos-unstalbe, but it doesn’t pass the argv[0] requirements and also doesn’t link liblzma. Also, fedora.

    Btw, https://security.archlinux.org/ASA-202403-1

    • SpaceCowboy@lemmy.ca
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      6 months ago

      Sid was that dickhead in Toystory that broke the toys.

      If you’re running debian sid and not expecting it to be a buggy insecure mess, then you’re doing debian wrong.

      • milicent_bystandr@lemm.ee
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        Yes, but Arch, though it had the compromised package, it appears the package didn’t actually compromise Arch because of how both Arch and the attack were set up.

      • fl42v@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        6 months ago

        Unlike arch that has no “stable”. Yap, sure; idk what it was supposed to mean, tho.

  • yuki!@lemmy.world
    link
    fedilink
    English
    arrow-up
    15
    ·
    edit-2
    6 months ago

    Bro WTF. How about you actually read up on the backdoor before slandering Arch. The backdoor DOES NOT affect Arch.

  • ZephrC@lemm.ee
    link
    fedilink
    arrow-up
    11
    ·
    6 months ago

    OpenSUSE Tumbleweed has it. The Fedora 40 beta has it. Its just a result of being bleeding edge. Arch doesn’t have exclusive rights to that.

  • lemmyvore@feddit.nl
    link
    fedilink
    English
    arrow-up
    5
    ·
    6 months ago

    I thought Arch was the only rolling distro that doesn’t have the backdoor. Its sshd is not linked with liblzma, and even if it were, they compile xz directly from git so they wouldn’t have gotten the backdoor anyway.

    • angel@iusearchlinux.fyi
      link
      fedilink
      arrow-up
      1
      ·
      6 months ago

      TBF they only switched to building from git after they were notified of the backdoor yesterday. Prior to that, the source tarball was used.

    • qwioeue@lemmy.worldOP
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      6 months ago

      liblzma is the problem. sshd is just the first thing they found that it is attacking. liblzma is used by firefox and many other critical packages.

      • Rustmilian@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 months ago

        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)"
        
        • qwioeue@lemmy.worldOP
          link
          fedilink
          arrow-up
          1
          arrow-down
          2
          ·
          edit-2
          6 months ago

          Yes, this sshd attack vector isn’t possible. However, they haven’t decomposed the exploit and we don’t know the extent of the attack. The reporter of the issue just scratched the surface. If you are using Arch, you should run pacman right now to downgrade.

          • HopFlop@discuss.tchncs.de
            link
            fedilink
            arrow-up
            3
            ·
            6 months ago

            If you are using Arch, you should run pacman right now to downgrade.

            No, just update. It’s already fixed. Thats the point of rolling release.

          • Fubarberry@sopuli.xyz
            link
            fedilink
            English
            arrow-up
            1
            ·
            6 months ago

            They actually have an upgrade fix for it, at least for the known parts of it. Doing a standard system upgrade will replace the xz package with one with the known backdoor removed.

    • Shareni@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      6 months ago

      Just Arch users being delusional. Every recent thread that had Arch mentioned in the comments has some variation of “Arch is the most stable distro” or “Stable distros have more issues than Arch”.

    • chrash0@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      6 months ago

      i think it’s a matter of perspective. if i’m deploying some containers or servers on a system that has well defined dependencies then i think Debian wins in a stability argument.

      for me, i’m installing a bunch of experimental or bleeding edge stuff that is hard to manage in even a non LTS Debian system. i don’t need my CUDA drivers to be battle tested, and i don’t want to add a bunch of sketchy links to APT because i want to install a nightly version of neovim with my package manager. Arch makes that stuff simple, reliable, and stable, at least in comparison.

      • laurelraven@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        3
        ·
        6 months ago

        “Stable” doesn’t mean “doesn’t crash”, it means “low frequency of changes”. Debian only makes changing updates every few years, and you can wait a few more years before even taking those changes without losing security support while Arch makes changing updates pretty much every time a package you have installed does.

        In no way is Arch more stable than Debian (other than maybe Debian Unstable/Sid, but even then it’s likely a bit of a wash)

      • Possibly linux@lemmy.zip
        link
        fedilink
        English
        arrow-up
        0
        arrow-down
        1
        ·
        6 months ago

        If you are adding sources to Debian you are doing it wrong. Use flatpak or Distrobox although distrobox is still affected

    • MyNamesNotRobert@lemmynsfw.com
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      edit-2
      6 months ago

      In my experience they’re the same from a reliability standpoint. Stuff on Arch will break for no reason after an update. Stuff on Debian will break for no reason after an update. It’s just as difficult to solve reliability problems on both.

      Because Debian isn’t a rolling release you will often run into issues where a bug got fixed in a future version of whatever program it is but not the one that’s available in the repository. Try using yt-dlp on any stable Debian installation and it won’t work for example.

      Arch isn’t without its issues. Half of the good stuff is on the AUR, and fuck the AUR. Stuff only installs without issues half the time. Good luck installing stuff that needs like 13+ other AUR packages as dependencies because non of that shit can be installed automatically. On other distros,all that stuff can be installed automatically and easily with a single command.

      I use Arch btw.

      • dan@upvote.au
        link
        fedilink
        arrow-up
        2
        ·
        6 months ago

        Stuff on Debian will break for no reason after an update

        I have never had this happen on Debian servers and I’ve been using it for around 20 years. The only time I broke a Debian system was my fault - I tried to upgrade an old server from Debian 10 to 12. It’s only supported to upgrade one version at a time. Had to restore from backup and upgrade to Debian 11 first, then to 12.

        • scoobford@lemmy.zip
          link
          fedilink
          arrow-up
          1
          ·
          6 months ago

          I’ve had the exact opposite experience. I switched to Arch when proton came out, and I haven’t had a system breakage since that wasn’t directly caused by my actions.

          Debian upgrades would basically fail to boot about 20% of the time before that.

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      2
      ·
      6 months ago

      It is not entirely clear either this exploit can affect other parts of the system. This is one those things you need to take extremely seriously

  • Allero@lemmy.today
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    6 months ago

    Arch is not vulnerable to this attack vector. Fedora Rawhide, OpenSUSE Tumbleweed and Debian Testing are.

  • carl://@upload.chat
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    6 months ago

    Arch has already updated XZ by relying on the source code repository itself instead of the tarballs that did have the manipulations in them.

    It’s not ideal since we still rely on a potentially *otherwise* compromised piece of code still but it’s a quick and effective workaround without massive technical trouble for the issue at hand.

  • RegalPotoo@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    6 months ago

    https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/

    There are no known reports of those versions being incorporated into any production releases for major Linux distributions, but both Red Hat and Debian reported that recently published beta releases used at least one of the backdoored versions […] A stable release of Arch Linux is also affected. That distribution, however, isn’t used in production systems.

    Ouch

    • mlg@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      6 months ago

      Very common compression utility for LZMA (.xz file)

      Similar to .gzip, .zip, etc.