• rtxn@lemmy.worldM
    link
    fedilink
    arrow-up
    39
    arrow-down
    1
    ·
    edit-2
    1 day ago

    The AUR is still safer. One, it is at least minimally moderated. If a malicious package is detected, it can be reported and removed. Two, the installer is usually not just a black box executable. Three, most of the build and runtime dependencies are from the official Arch repos, which provides some protection against supply chain attacks. For Windows installers, you have to trust the distributor to bundle clean DLLs (for that matter, the same applies to AppImages).

    But if it starts downloading anything from NPM… ^C and run.

    • Lucy :3@feddit.org
      link
      fedilink
      arrow-up
      20
      ·
      1 day ago

      The most unsafe factor of the AUR is aur helpers and their goal to dumb everything down and streamline the process as if the AUR where an official repo

      • CubitOom@infosec.pub
        link
        fedilink
        English
        arrow-up
        8
        ·
        1 day ago

        I’m not entirely sure I agree, I think the issue is with default settings.

        Like you could use both yay and paru to diff the PKGBUILD of the most recent updat and then read it, and then approve each. And I think that’s pretty helpful. But you could also just blindly accept the update with the right config or flag and that is not a good practice.

        • bitfucker@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          20 hours ago

          Yeah, use and promote aurto instead. They require you to trust the maintainer and would remove the package from the local repo if the maintainer is changed

          • CubitOom@infosec.pub
            link
            fedilink
            English
            arrow-up
            2
            ·
            15 hours ago

            I’m not sure if loosing the maintainer is to only thing we should be going off of here, but I like the name.

            • bitfucker@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              14 hours ago

              Well, it is just like a distro maintainer account anyway. If the maintainer account is compromised then gg for the whole distro. That’s what happens with other supply chain attacks as well and yes, I do think we need a way to fix that without compromising on ease of usability

              • CubitOom@infosec.pub
                link
                fedilink
                English
                arrow-up
                1
                ·
                13 hours ago

                We arnt talking about a distro maintainer, but an aur package maintainer, which can be anyone.

                • bitfucker@programming.dev
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  13 hours ago

                  Yes, and that is no different than distro maintainer that maintains the infrastructure and package. Anyone can volunteer. That’s how xz is compromised. The point is that aurto trust models mimic those of other package managers. Trusting the authors implicitly trust the code. The only other special things from distro maintainer is their PGP signatures are required to perform release on the main repo. This is better because as I stated earlier, reviewing PKGBUILDS would encourage people to just skip it. Not everyone has the time for that. But when a maintainer changes? Aurto removes the package for you to perform that first trust again on the new maintainer. This is no different than if you update the arch keyring just more manual

                  • CubitOom@infosec.pub
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    12 hours ago

                    No, an aur maintainer is not the same a distro maintainer.

                    But I do agree it would be good to atleast stop and evaluate when the maintainer changes or a package looses the maintainer at a minimum.