16
nixpkgs > aur (programming.dev)
submitted 4 months ago by to c/linux_memes@programming.dev
1 comment fedilink hide all child comments
 

1 comment

sorted by: hot top controversial new old
[–] 2 points 4 months ago

nixpkgs has so many packets, there's no way it hasn't been hacked yet.

  • permalink
  • fedilink
  • source
    •
    31 comments in c/linuxmemes@lemmy.world view that post
    [–] 149 points 4 months ago (10 children)

    As a nix user, I wouldn't laugh. We are vulnerable to this type of attack as well.

    Heck, it's surprising we aren't full of malware considering how many packages there are, and an easy supply chain attack vector with auto RyanTM PRs.

  • permalink
  • fedilink
  • source
  • hideshow 10 child comments
    •
  • [–] 15 points 4 months ago (4 children)

    It's possible, but at the very least someone glances over the derivation since it's part of the actual nixpkgs repo right? AUR on the other hand is a wild west.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 15 points 4 months ago (1 child)

    Yeah if the url is https://i_hack.you/ yeah that will be easy to spot. But imagine an attacker just to a "patch update", updating the url and hash to the malicious repository, and use a typo squatted domain/repository, that will make it harder to spot.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 13 points 4 months ago

    No, it would actually be quite easy to spot.

    Nixpkgs templates the source code url fro the url, and then it injects a variable

    Here is an example from bash:

    pname = "bash${lib.optionalString interactive "-interactive"}";
    version = "5.3${fa.patch_suffix}";
    patch_suffix = "p${toString (builtins.length upstreamPatches)}";

    src = fetchurl {
      url = "mirror://gnu/bash/bash-$%7Blib.removeSuffix fa.patch_suffix fa.version}.tar.gz";
      hash = "sha256-DVzYaWX4aaJs9k9Lcb57lvkKO6iz104n6OnZ1VUPMbo=";
    };

    If the url were to be changed, it would show up as a change in git when someone is reviewing before merging.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 7 points 4 months ago

    Yes, on one hand every commit to nixpkgs needs review (to some degree) on the other hand there are far too many committers to nixpkgs.

    There are also gaps such as the bots to auto-merge packages with maintainer approval, so a simple attack looks like this:

    1. Submit a package with you as a maintainer.
    2. Create a new GitHub account and send a malicious update to that package.
    3. Use a bot to merge with maintainer approval.

    So nixpkgs is better than the AUR, but it isn't great and unlike Arch has no separate official repos.

  • permalink
  • fedilink
  • source
  • parent
  • [+] [S] -14 points 4 months ago (2 children)

    I don't see how it would happen. Nix is immune bc hashes are constantly checked, you can't swap in malicious code without a person noticing bc it might throw a mismatched hash error. Also nixpkgs has been really good about vetting packages, I don't expect them to look too closely into the source codes of everything but if something malicious were to happen like what is happening to AUR someone would see it way faster

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 25 points 4 months ago

    The AUR attack attacked the build files. On nix, you could easily set a new download url for the package, set the new hash, and claim the project has moved to a new repo/site.

    That would require a second person to vet on it, but it could be seen as normal for a maintainer not in the know about the project.

    New packages are harder to pass, but it could also work.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 59 points 4 months ago (4 children)

    I remember when, I think it was either a log4j or CUPS malware attack, Debian remained unaffected because the packages in its repos was too old.

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
    • [–] 48 points 4 months ago*

    AUR: it happened to me, and one day it will happen to you!

    This is still the shai hulud worm.

    There’s no reason nixpkgs hasn’t been hacked yet. It jest depends on a few devs credentials being stolen, either by vscode, an npm package, a pypi dep, etc.

  • permalink
  • fedilink
  • source
    •
    [–] 13 points 4 months ago*

    COPR: "You guys are actually sharing your packages with other people?"

  • permalink
  • fedilink
  • source
    •
    [–] 13 points 4 months ago (4 children)

    I mean, no one is stopping you from using Nix on Arch

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 12 points 4 months ago (3 children)

    I believe I even got the reverse, pacman working on Nix (I've also gotten it and archiso working on Fedora)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
    • [–] 22 points 4 months ago (1 child)

    Running both ... Nixpkgs will rightfully laugh about this - in about a month once they caught up on recent events.

    Loving both arch and nixos though!

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [–] 7 points 4 months ago

    Y'all just haven't noticed yet.

  • permalink
  • fedilink
  • source
    •
    [–] 10 points 4 months ago*

    Comparing the AUR to nixpkgs is like comparing the NUR and random flakes to the main Arch repositories.

    Had the AUR been prefixing the package names with the maintainer name like the NUR does, then it would not be possible to do the orphan adoption attack at the same scale. (Instead a bunch of duplicates with higher version numbers would pop up, prompting users to switch)

  • permalink
  • fedilink
  • source
    •
    [–] 1 point 4 months ago (3 children)

    We're any chaotic-aur packages affected?

  • permalink
  • fedilink
  • source
  • hideshow 3 child comments
    •