Jordan Gloor / How-To Geek
The Arch Linux AUR repository contains community-driven software that’s safe to use if you take some simple precautions. Even if you don’t understand shell scripting, there are indicators that you can use to judge whether a package is safe or not.
The AUR is one of the jewels in the crown of Arch Linux, providing thousands of additional software packages. But is this user-driven repository safe to use, or should you avoid it?
The AUR (Arch User Repository) is a community-driven software repository that provides upwards of 85,000 software packages to Arch Linux users. Unlike other Arch repositories such as the core, extra, and multilib repositories, the AUR doesn’t host ready-to-install packages. In fact, it doesn’t host binary files or packaged software at all.
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
The PKGBUILD instructions download source code files and other files that are required to create the package archive. The
pacman the 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.
RELATED: How to Update Arch Linux
It’s a very rare occurrence, but sometimes things slip through the net, despite the diligence of 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?
Even without code reviews, there are steps you can take to help you decide whether you can trust an AUR package.
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 were 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.
There are user comments at the foot of each AUR page. These can extend over many pages. See what other users are saying about the package, and what kind of questions they ask. Also, see what solutions are offered to issues that are raised. Are there any recent comments? Does this package still have an active user base?
If you register on the AUR and create a free account you’ll be able to leave comments and ask questions. Also, use other resources like forums and subreddits to ask about the package.
Even if you don’t understand shell scripts, there are still a couple of things you can check.
A common way to access the AUR is with a command line “AUR helper” such as, 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, your 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
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 it into the new “yay” directory.
Let’s see what files we have.
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.
A well-formed PKGBUILD file that follows conventions will create variables to hold the URLs that it uses. This gives us a neat list at 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
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.
But we’ll carry on and look a little deeper.
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
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
mv commands, nor should they need to reference anything in the “/dev” directory. If the PKGBUILD directly calls
pacman, or mentions
systemd, or any other vital system component such as
grub, treating 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
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 they 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
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.
Linux usually has many ways to skin any given cat.
RELATED: How to Install Arch Linux From a GUI