• punkcoder@lemmy.worldEnglish
    1·
    13 days ago

    Real talk for a moment, there isn’t a system alive that currently solves the supply chain attack issue. there’s a trade-off between usability, and security. You can be a secure as you want to be, all it takes is a small accident by one developer in a package that you’re using, even if they’re using gpg signing to accidentally upload A package that’s been tampered. It stinks, but that’s the reality. What I think should be applauded is the thoroughness that the arch developers are going through the repo right now trying to find these packages. I don’t know the specifics, but if they’re like other open source developers, they’re unpaid people doing this out of their love for the software and community. and more than likely, this is a headache on top of headaches that they already have that they’re doing for the love of the community.

    • RustyNova@lemmy.world
      0·
      12 days ago

      Idk how the AUR works but I like that nix fetch the source from the repo and also check its hash from a maintainer provided one. Prevents repo hijacking.

      Although it’s still pretty much vulnerable if the attacker controls both the nix file and the repo

      • bitfucker@programming.dev
        1·
        12 days ago

        Every *-git package also fetch it from the repo. The apt analogy is someone haven’t been maintaining the nixpkg and then it gets adopted by someone else. Now that someone else change the build script to be malware. So it is no fault of the upstream

      • sudo@programming.dev
        1·
        12 days ago

        That wouldn’t have fixed the AUR incident because the attacker updated the PKGBUILD which is roughly the same as the nixfile. And there are no packages provided by the AUR, just PKGBUILDs. You always build the package yourself locally.

  • muusemuuse@sh.itjust.worksEnglish
    1·
    13 days ago

    Back when I was learning arch they made sure you understood AUR is an option, it was never a good option. Even then the risks were just not worth it.

    My understanding the AUR was it was supposed to be a “here’s how I made this work.” But it gets treated as a generic repo all the time so…this.

  • carmo55@lemmy.zip
    1·
    12 days ago

    Why is adoption a thing in this way though? People compare AUR to github which seems very apt, but on Github no-one can come and take over the URL of an abandoned repo for rhemselves, if someone wants to start maintaining and the old owner is MIA, they have to make a fork. Why doesn’t AUR work the same way but instead allows anyone to take over any abandoned project with no checks?

    • communism@lemmy.ml
      1·
      12 days ago

      The forking option wouldn’t work as well as it does on github because AUR packages are not namespaced like GitHub repos, e.g. communism/mypackage; instead it’s just mypackage. So if adoption required a new name you’d have mypackage-cont, mypackage-cont-cont, or whatever. And it wouldn’t really be possible to introduce username namespacing because AUR packages are just Pacman packages that are community-contributed rather than official, and Pacman, like most package managers, doesn’t namespace their package names; firefox is just firefox rather than, say, mozilla/firefox. Some AUR packages get added to the official repos so when you do, e.g. yay -Syu, you’ll then install the official package if you previously had the AUR package installed as it has the same name.

      There isn’t a perfect solution. Even if package adoptions were moderated, someone could take over a package and initially push a genuine commit, and then their next commit is malicious. Reviewing every single AUR commit would be incredibly labour-intensive. Possibly you could add automated checks for commits that suddenly add an npm install or other suspicious command with regex, but attackers could just get cleverer about avoiding those regex checks. Imo the best solution is just more widespread warnings about the fact that AUR packages are community-contributed with no guarantees of safety (e.g. on the Arch wiki where it sometimes suggests users install AUR packages), and AUR helpers forcing users to read PKGBUILDs before installation.

  • agentTeiko@piefed.socialEnglish
    0·
    13 days ago

    I’m not going to lie the aur never made sense to me. If you are going to go to all that trouble why not just package it. Source packages are a thing.

    • Err(()).unwrap()@lemmy.world
      1·
      13 days ago

      The developers themselves are often not the package maintainers. Before a package is published or updated in one of the official Arch repos, it has to be built, tested, and sometimes patched (which is why you see a -1, -2, etc. appended to the package version), in order to work correctly not just on its own but in an Arch system with Arch packages that it is likely to encounter. The process is not as thorough as Debian for example, but it’s still the responsibility of the package maintainer. If the package is still in early development, deprecated (e.g. wine32), an out-of-tree kernel module (e.g. xpadneo-dkms), or is meant to be built from the latest available commit (any number of *-git packages), the AUR is a convenient way to share PKGBUILD files rather than have the user build the software manually based on a readme, if it even includes build instructions. The PKGBUILD is then ingested by makepkg, which both configures the environment and builds the software, and outputs a package that can then be installed and managed by Pacman.

      The caveat is that packages built from the AUR are not vetted by any package maintainers. They can have bugs, they might depend on outdated or no-longer-existent packages, or might contain malware.