Because there is this myth that only Windows users get infected because Windows is insecure, that packages are vetted, that code being open source means that a backdoor insertion would quickly be discovered, and so on.

Packages are vetted, in the repos, just not in AUR.

They also keep tools that would easily/automatically build and install packages from AUR out of the main repos, to encourage manual handling and individual consideration of AUR package build scripts.

Also this malware was found in AUR within a few hours of it going up.

Exactly. It's actually kind of a success story for the AUR, since they found the malware so quickly.

Of course, it would be more interesting if we could scan or survey the AUR to get a percentage of suspicious packages. I've long been under the impression that some popular AUR packages (e.g. Google Chrome) are pretty safe from tampering. For anything else, I glance over the PKGBUILD to make sure it's not doing anything obviously fishy, and I've never noticed anything.

How are official Arch packages vetted?

They are built by the core Arch developers, or as in the case of the 'community' repo, by 'Trusted Users', the latter being people who have done high quality maintaining of packages in the AUR and shown good community involvement.

Having met these criterias, they need to be sponsored by an existing TU, and then it will be put up to a vote.

Do you know if there is any kind of review process? For example, let’s say a core maintainer’s machine is compromised and the attacker submits a new package on their behalf. Does anyone else need to review and sign off on the new package?

Thank you!

Depends on what you deem "vetted". Builds from source from a trusted source. Try ask if they can PGP sign their sources. Builds fine. Pushed to the repos. If its an package from core or extra it goes through testing for a few days.

Also been a push towards reproducible builds, and the stones have been laid with pacman 5.1.

Unofficial user repositories contain unofficial user software. Shockers!

Sarcasm aside, I think a lot of the pearl-clutching over this incident is down to people not understanding the difference between the official repositories and the AUR.

Of course, one should be careful about what one installs on their system. Even more so an Arch user, which should be technical saavy in the first place.

Anyways, I know I don't manually review everything I install on my system, I trust the packet manager.

I'm not an Arch user so I don't know, but doest the AUR repo have some kind of code signing or automatic analysis of the packages?

AUR is not an "official" repository at all -- indeed the acronym stands for "Arch User Repository". Kinda like github, you can go put whatever you want in there, and people can download and install it on their machines if they want to.

The "correct" way to install something from AUR is to go grab the install script, READ THROUGH IT CAREFULLY, then knowing that you just downloaded a thing uploaded by someone unafilliated with Arch, you make your decision on whether or not to run/install it. That said, there are (non-official) package managers that you can use which give you a package-manager-like experience installing packages from AUR and do a pretty good job of sweeping all of that under the rug. Convenient? yes; a good idea? it's your system, you decide (my opinion is 'no').

> a good idea? it's your system, you decide (my opinion is 'no').

This frustrates me. Because there is a large vocal group that opposes the use of yaourt (the most popular AUR package manager), I spent a year building packages by hand, just to see if there was something I was missing. I was not. It's just a complete PITA. In the end, I wrote scripts that just about duplicated yaourt -- checks for new versions of packages that I've installed, downloads the latest comments so I can see if there has been any controversy, checks for and installs dependencies, etc, etc.

There is nothing in the manual process that makes it more safe than installing with yaourt. Yaourt prompts you to edit the PKGBUILD file (and even defaults to this!). It is just as easy (and in fact, I think easier) to neglect to check what it's doing when you are building by hand.

After a year of building by hand, I went back to yaourt because I have better things to do with my time than write scripts that duplicate it.

I think the real issue is that many people do not want to legitimise AUR as a source of packages for everyday people. I can sympathise with this point of view and even agree to it to a certain extent. However, avoiding using a tool like yaourt is cutting off your nose to spite your face, IMHO.

> There is nothing in the manual process that makes it more safe than installing with yaourt. Yaourt prompts you to edit the PKGBUILD file (and even defaults to this!). It is just as easy (and in fact, I think easier) to neglect to check what it's doing when you are building by hand.

I get your point, but I think part of the reason for the official stance against AUR helpers is that they incline users to skip any manual vetting of the PKGBUILDs on their own. In practice, you're always going to have some subset of the population who won't even look at the source PKGBUILDs (helper or not), but I think this is a valid concern. If you download the package sources manually, the effort required to type "makepkg" versus "less PKGBUILD" isn't significant. Contrast this to using a helper, where pressing a key to continue building is an awful lot more tempting than having the helper open the PKGBUILD in your editor (where you now have to press many more keys to continue)--regardless of the defaults.

What I tend to do is use an AUR helper to download the package sources and then manually build them from there. Helpers are incredibly useful for searching/downloading sources from the command line, but I'm not completely convinced having them build/install everything unattended is a particularly great idea. Part of this is the nature of the AUR and part of this is because if you use enough packages from the AUR, sooner or later, you're going to have to intervene and fix something (which defeats the point of using the helper in the first place). Plus, using the helper as a glorified fetch tool gives you something of an intermediate package cache as opposed to dumping everything in /tmp and nuking it between boots.

That said, I do agree it's more to avoid legitimizing the AUR. There's good reasons for this (legal and otherwise). But I think it's important for people to decide precisely how they wish to use the AUR as long as they understand the repercussions.

Also, I believe yaourt is considered deprecated as it hasn't seen updates in quite some time. I'd suggest something else like aurman or yay.

I think you're clutching at straws to be honest.

> If you download the package sources manually, the effort required to type "makepkg" versus "less PKGBUILD" isn't significant. Contrast this to using a helper, where pressing a key to continue building is an awful lot more tempting than having the helper open the PKGBUILD in your editor (where you now have to press many more keys to continue)--regardless of the defaults.

You could make the same argument about effort to skip checking being fewer keystrokes to argue that yaourt makes its more convenient to check because that is also fewer keystrokes than typing an additional command manually in the command line. Thus I think the actual reality is people who are lazy will skip a self audit regardless of how they choose to build the package. Ie youart isn't problem.

> Plus, using the helper as a glorified fetch tool gives you something of an intermediate package cache as opposed to dumping everything in /tmp and nuking it between boots.

So change the build location. It's all configurable. /tmp makes sense as a default but I have mine set elsewhere. On a previous system I even had yaourt configured to build in its own ZFS tank.

> Also, I believe yaourt is considered deprecated as it hasn't seen updates in quite some time. I'd suggest something else like aurman or yay.

I often hear the same complaint made about Android apps (re it's not been updated in a while) but when it already does everything it needs to then why should it need to see further updates? It's not like yaourt doesn't keep track of security updates (I mean it's all just wrappers around GNU and BSD tools so if there's a bug in tar or OpenSSL then they will be updated independently anyway).

I've been using yaourt for several years and frankly I've never once felt "damn, this thing needs more maintenance".

AFAIK yaourt specifically is discouraged because its possible for a malicious PKGBUILD file to execute code before it is displayed to you (as a consequence of the way yaourt parses the files). Other AUR helpers do not have this problem.

In my opinion, this is a hard problem and not one that we can expect Arch Linux to take on or solve. We're talking about how we establish that a software package (source code, build script, binaries, etc.) can be deemed trustworthy such that we feel comfortable installing it onto our machine (which may hold important data, personal, financial, etc.) I don't think anyone has a good solution, with the Apple App Store at one extreme and (in my opinion) something like AUR at the other.

Arch discourages tools like yaourt because it makes it so easy to install some an unvetted package and that opens you up to the very real risk of installing malware. As you point out, downloading the package and building it isn't any safer if you don't read through the script. It's easy to make the argument that a casual read through of the package file will only catch the most obviously bad packages and a clever person could easily find better ways to hide their malware payload, so why bother looking at all?

If you aren't going to read the package files, you may as well use a tool like yaourt; there's effectively no difference. In my own experience it's rare that I have to install something from AUR so I can take the time to briefly scroll through the package files and check where the source code is coming from, easy stuff like that.

In the back of my mind, I understand I'm taking a risk; I think that's what Arch is trying to accomplish by discouraging tools like yaourt.

I can't speak for all AUR managers but the one I use (yaourt) is probably the most popular one on Arch and it definitely does prompt you to audit the package before you compile it.

No, AUR packages are PKGBUILD files, which are essentially little batch scripts that run inside a fakeroot.

IMHO, the danger of a PKGBUILD itself doing something nasty is small--it would be limited to things like recording `uname -a`, listing all your installed packages: the things mentioned in the article.

The real danger is that the PKGBUILD is installing some software, which you will later run with full user privileges. If you don't notice that the Git repo listed in the PKGBUILD file is wrong, you won't notice that you're actually installing a backdoored version of the package.

The PKBUILD runs in the fakeroot, but AFAIK the .install files (postinstall hooks etc) run on the host system directly, with root permission. Definitely something you will always want to review.

(Also, I don't really get the critique of tools like yaourt, since they make it easy to inspect the PKGBUILD and - if present - install files. The tool simplifies downloading, you still need to review yourself!)

All the install hooks are run chrooted inside the pacman install directory.

But, yeah, they run as root, so they could still do something nasty at install time. Not when you `makepkg` the PKGBUILD, though.

The AUR repo is, basically, a free for all. It’s not the official repository, which is trustworthy - it’s just a hosting space for user-provided build instructions.