1. 35

  2. 8

    At least the perpetrator didn’t test their code. This is one of few instances where not testing code leads to the better outcome.

    1. 6

      OK but the tag line is asinine. As a regular user of a Linux distribution it is actually impossible for me to take the time to do a full analysis on every package I install to get work done.

      SOME level of trust has to be there or else the whole idea of a Linux distro can’t work.

      1. 10

        Well, AUR specifically isn’t part of the actual Arch distro. It’s no safer than the curl | bash invocations on github.

        1. 4

          But it makes your wonder if there is no middle-ground between the AUR and the community repository. Have a Git{Hub,Lab,ea} repository where the community can do pull requests for new packages and updates, but the pull requests are reviewed by trusted users or developers. And then build the packages on trusted infrastructure.

          1. 9

            This is how the OpenBSD ports tree works. Anyone can send a new port or an update to the ports@ mailing list. It then gets tested & committed by developers.

            In this specific instance, I think what hurt Arch here is too good tooling. The community developed a lot of automation tools that boil down third party package installs to pressing enter a bunch of times - even with all the warnings present people stopped reviewing the packages. If I recall correctly, the main point of AUR was to gather community packages then promote the popular ones (by votes) to trusted repositories - essentially the promotion to trusted repos lost meaning as everyone can install yaourt/pacaur or $pkgmgr du jour and just go on with their life.

          2. 2

            It’s no safer than the curl | bash invocations on github.

            Highly disagree. Using the AUR without any supporting tools like pacaur, you’re cloning into a git repository to retrieve the PKGBUILD and supporting files, so you have the opportunity to view them. With pacaur, you’re shown the PKGBUILD at first install so you can make sure nothing’s malicious, and then you’re shown diffs when the package version updates. That’s MUCH better than curl | bash already.

            1. 1

              Also, while you shouldn’t rely on others to spot malicious code, the fact that the malicious modifications were spotted and reverted after about 9 hours shows that the AUR is subject to at least slightly more scrutiny than random scripts from github or elsewhere are.

              Admittedly, it doesn’t sound like this particular attack was very sophisticated or well hidden.

        2. 3

          I am honestly surprised this hasn’t happened before. Always check what you are downloading from the AUR.

          1. 0

            Might’ve happened and we don’t know about it yet

          2. 2

            It was a mistake to add a pastebin URL in the AUR build script, it’s way too easy to detect and it looks fishy from the first glance. Instead, re-package the upstream tarball with the script and put it in a github release. AUR users might review the BUILD script but probably won’t look at the upstream code and might not notice the URL switch if it comes from a legit-looking source like github.

            That’s what a more sophisticated attacker would do.

            1. 1

              Has anyone seen what the other two packages mentioned in the email are/were?

              (Seems even if they were accidentally installed by someone they won’t do any harm, but seems odd not to name them so people can check.)

              1. 3

                I found someone on reddit mentioning balz and minergate as the other two packages.

                1. 1