The AUR hosts package build files, called PKGBUILDs. These are shell scripts that are run by the Arch makepkg tool. When makepkg runs, it looks for a file called “PKGBUILD.” If it finds one, it opens it and follows the instructions inside it to create a software package archive on your computer. If you’re familiar with compiling on the command line, a PKGBUILD file and makepkg work together in a similar fashion to a MAKEFILE and the make utility.

The PKGBUILD instructions download source code files and other files that are required to create the package archive. The pacman tool is called automatically to install the software from the package archive.

At the risk of introducing some confusion, some AUR packages do deliver pre-compiled binaries. But those binaries are not hosted in the AUR, they’re stored elsewhere on the internet. The AUR entry for those packages only holds a PKGBUILD file that downloads the pre-compiled binary to your computer.

The AUR allows anyone to create a PKGBUILD for a piece of software they’d like to make available for other Arch users. These can be open or closed source packages, or even commercial software. AUR Packages that get sufficient user votes can be promoted to a regular Arch repository called the community repository.

The problem with the AUR becomes apparent when you boil it right down to basics. It’s a collection of scripts from random users across the internet. And they’d like you to run them on your computer. To mitigate the risks, uploaded scripts are reviewed by qualified, respected volunteers, known as trusted users. The trusted users inspect and test the PKGBUILDS, and remove any containing dangerous mistakes or malicious intentions.

The Dangers of Using the AUR

It’s a very rare occurrence, but sometimes things slip through the net, despite the diligence of the trusted users. Back in 2015, a Valve Software Steam script erased your home directory if you’d previously moved the Steam directory to a new location.

More sinister was the incident in 2005, when an orphaned AUR package was taken over by a new maintainer who deliberately added malicious code to the PKGBUILD file. These examples are old and uncommon, but the same things could happen again.

Of course, if you’re sufficiently skilled, you can review the contents of the PKGBUILD file yourself. This transparency is one of the strengths of the AUR, but it does require sufficient scripting knowledge to benefit from it. And that only covers the PKGBUILD file itself. If it pulls in a mass of application source code, theoretically that should be checked too.

Other dangers in using the AUR are distribution based. Not all Arch-based distributions are sufficiently Arch-like for the AUR to work flawlessly. The AUR assumes it is installing onto genuine Arch Linux, and a fully-patched and updated version, at that. Manjaro, for example, doesn’t officially support the AUR even though it is Arch-based.

But, given that your distribution does support the AUR, what can you do to make sure you’re using it as safely as possible, whether you understand source code and shell scripts or not?

There’s a page in the AUR for every package. The package’s webpage describes the package, what dependencies it has, which packages depend on it, and other useful information. Start your investigation by going to the AUR and searching for your package.

Packages can be voted for by users, and there’s a popularity score given to each package too. The more votes and the higher the popularity, the better. It means the package is well-known and widely-used. In other words, it is a reputable package.

The reputation of the package is a good indication of its trustworthiness. The more people who use it, and vote for it, the more comfortable you can feel about using it.

In the “Package Details” section you’ll see its votes, popularity score, and two dates. One is when the packages was first introduced into the AUR and the second is when the package was last updated.

The “Last Updated” date will tell you whether the package is being actively maintained. Packages that have been dormant for a long time should be treated with caution.

Also check the “Upstream URL” and verify that it goes to a valid web page or code repository for the package or project. If it doesn’t, something’s wrong.

Check the Contents of the PKGBUILD and Other Files

A common way to access the AUR is with a command line “AUR helper” such as yay, but you can also use the AUR in a hands-on, manual way.

Good AUR helpers give you the option to inspect the PKGBUILD file, halting the installation if you don’t want to proceed. In the manual process, you search for the package on the AUR and download the PKGBUILD file and inspect it before you use it. If you’re happy to proceed after you’ve reviewed it, you run makepkg manually.

It’s a good idea to install at least one package manually, so you know the mechanics of what the AUR helper is doing in the background. We’ll use the yay AUR helper as an example.

The package was first submitted in 2016 and was last updated in May 2023. At the time of writing, that’s a very recent update. Also notable is the original submitter, the current maintainer, and the last person to package the software, are all the same person. That continuity is a good sign.

Click the “Git Clone URL” URL link in the “Package Details” section to copy it to the clipboard.

In a terminal window, type “git clone”, a space, and then press Shift+Ctrl+V to paste the URL onto the command line. Press “Enter” to start the download.

git clone https://aur.archlinux.org/yay.git

When the download is complete, change into the new “yay” directory.

cd yay

ls

There’s a single file, the PKGBUILD file. Often there are one or two additional helper files. Look through those too. We’ll use less to read our single file.

less PKGBUILD

A well-formed PKGBUILD file that follows conventions will create variables to hold the URLs that it uses. This gives us a neat list the top of the file of the URLs the PKGBUILD will reference. In this case, there’s only one.

We can see that it is pointing to a GitHub page for the yay project.

The GitHub page is owned by a user with the same name as the maintainer that was listed on the AUR page for this package. These are two good indications that this is a safe package.

Use the less search feature to search the file for uses of wget or curl. Both of these tools can be used to retrieve remote files. A well-behaved PKGBUILD should have no need for such activity.

If you do find any occurrences, treat them as a red flag and don’t install the package until you are certain it is benign. What is the URL that the wget or curl commands are referencing? Do they look legitimate and related to the package? If you can get confirmation from a trusted source that the PKGBUILD is trustworthy, and it’s just written in a way that doesn’t follow conventions, you may still choose to install it.

Likewise, there’s no need for a PKGBUILD file to contain the rm or mv commands, nor should they have need to reference anything in the “/dev” directory. If the PKGBUILD directly calls pacman, or mentions systemctl, systemd, or any other vital system component such as grub, treat the PKGBUILD file as dangerous and don’t run it. You can perform the steps we’ve used so far even if you cannot read shell scripts. If you do know some shell scripting, you can review the actual code in the PKGBUILD.

People who write malicious code often try to hide its intentions by obfuscating it. They use minimalist, terse, impenetrable syntax so it’s hard to decipher what they are trying to do. If you see any lines that use redirection or call sed or awk , treat them as suspicious.

Copying those lines and dropping them into an online parser such as explainshell.com will unpack them so you can see what hey actually do. If you’re confronted with a densely-packed mess of brackets, semicolons, and ampersands, it’s worth using an online parser to double-check you’ve correctly interpreted what the line is trying to do. But in general, hard to read code is a warning sign.

PKGBUILD compiles and builds take place in a chroot environment.

These are isolated mini file systems that let developers sandbox processes by limiting their access to the rest of your computer’s file system, and reducing their access to other system commands.If the PKGBUILD is directly manipulating your home directory, treat that as a warning flag. Ensure you fully understand what it is doing before you decide to run it.

With extremely popular packages, you’re very likely to be safe. Because of the high number of users, issues get spotted faster and reported more quickly. You can do your part by reporting any issues you find, and upvoting good packages to improve their reputation.

If you find there is an issue with a package that makes you not want to install it, you can find yourself in a bind because you needed that package. One way forward is to ask on forums for suggestions of other packages that can satisfy that particular need.