AUR Security vs Convenience - What's Your Take?

General system Applications
1

Hi everyone,

Former Arch user here who has been using NixOS for the past few years.

Every now and then, like today, I get this strong urge to come back to Arch, even if just temporarily, to relive the experience since it’s been a while. However, there’s always one particular aspect of Arch that gives me pause and ultimately keeps me from making the switch back: the AUR (Arch User Repository).

Before I get into it, I want to be clear that this is not a post meant to criticize Arch or imply that NixOS is superior. Both distributions have their own set of pros and cons, and NixOS certainly has its fair share of drawbacks as well. I’m simply looking for some honest feedback from the Arch/EndeavourOS community about my concern.

The concern I’m talking about is the security of the AUR.

On NixOS, all packages come from the official nixpkgs repository, which is maintained through GitHub pull requests. Each package is reviewed, vetted, tested, and only then pushed to the repository when deemed safe. This centralized and strictly managed approach has always given me peace of mind when installing software.

With Arch and the AUR, though, it feels different and this has always been a mental block for me. While the AUR is incredibly vast and convenient, it feels a bit like the wild west. Anyone can upload a PKGBUILD, and unless you’re personally inspecting each PKGBUILD before installing or updating, there’s always an inherent risk. Realistically speaking, I imagine most users do not manually inspect PKGBUILDs every time they install or update something from the AUR, and I’m willing to bet my savings on that.

I’m aware that nixpkgs can actually be installed on Arch, which would theoretically solve the problem of package security. However, for me personally, that would defeat the purpose of switching back to Arch in the first place. One of the main reasons I sometimes feel drawn to use Arch again is because of the vast selection of packages available in the AUR, some of which are either missing from the nixpkgs repository or left unmaintained. So while I do value the higher level of security that NixOS provides, I also miss the convenience of having access to practically any package imaginable through the AUR. Unfortunately, that lingering concern about security always keeps me from making the switch.

So my questions to you all are:

  1. Do you personally inspect the PKGBUILD every time before installing a package or updating it from the AUR?
  2. What’s your general take on AUR security and how do you personally mitigate any potential risks?
  3. Has anything changed in recent years to make the AUR more secure or streamlined in terms of safety?

I’m strongly considering reinstalling Arch this week, but I really wanted to get some input from the community first. This has always been my biggest hesitation and, and I’d love to hear how some of you approach this concern.

2

Yes, this is easier than you think. yay and paru both have an option that only shows you the diffs when you update a package from the AUR so you only have to look at what changed. 90% of the time, the only changes are the versions and the sums.

For most of my updates this takes 10-15 seconds. Every once in a while you get one with substantive changes but these also don’t take long to review.

IMO, AUR is one of the safest 3rd party repos in all of Linux. Because you can easily inspect the PKGBUILDs for yourself and the tools make it easy to do this as part of the upgrade process. Also, PKGBUILDs are very easy to read since they are basically just scripts.

Another thing to consider is that most AUR packages are kept up to date very well. When a package isn’t updated, it will be flagged and your helper should warn you about this whenever you update.

Compare this to other places where the process to add packages might be sound but since updates are not frequent, the software itself will often be outdated software with known security issues.

11 Likes
3

Yes, this is mandatory IMO. I am familiar with PKGBUILD since I build packages myself so it doesn’t take a long time to verify for me. You can also visit the AUR webpage for the package and look at comments for any potential concerns

IMO there is risk only for unpopular and un-updated packages. For most packages if there are any issues you see them in the comments. This is safe since there are many eyes on the PKGBUILD since its public and transparent. Users can flag the packages if they have issues.

I don’t think so, I don’t know what recent means to you. Using nix packages as you say means you’re trusting the nix package maintainers to build the packages. Using AUR means you’re trusting yourself to verify the PKGBUILD and build the package locally and install it.

6 Likes
4

Very valid and good points. Appreciate the insight.

2 Likes
5

I suppose I never really considered it from this angle before. While there are valid arguments for both sides, I can see how the latter approach provides greater peace of mind, even if it means investing a bit more time and effort.

2 Likes
6

Something I say all the time is, “convenience is the opposite of control”.

While it isn’t always true, it often is — maybe 80/20, especially in the proprietary world.
In the open-source world, it is kinda 50/50 or maybe even the complete opposite.
At least, based on the apps/services I’ve used.

The general idea of the quote is that the more convenient something is, the less control you have over how it works or does things. Of course, if you become great at doing something, your idea of convenient significantly changes. Similar to “common sense”.

The first two responses cover everything else I would say, so this is all I have to add.

3 Likes
7

I will give my take because why not, however, I have not used NixOS so I can’t compare with that and can only talk about Arch.
I currently have 15 AUR packages and have had no issues so far with them. AUR packages are very transparent with installation process which makes them pretty secure in my book, the rest of the trust is in the developer of the software you are using which is separate from AUR. I will say that while this seems like a lot you get used to it pretty quickly and I like the level of control AUR offers over other methods.

But one thing to know about the AUR is the AUR doesn’t contain packages itself, more that it contains a collection of user made scripts to install packages from external sources such as github, gitlab etc. This is where the details on the PKGBUILD is important to know where the package comes from or what the install script will do on the system.

So one thing to check on AUR page is the upstream URL the package is coming from and inspecting the URLs in the PKGBUILD itself to make sure the software is coming from a legitimate source, legitimate as in from the developer you trust.
The comments can tell you if there is any issues with the package, the date of the package is useful as it’s best to avoid packages that are too old most of the time but I have never found packages out of date really.

The final thing is that while AUR packages are not official (As in official Arch repository) it is filled with official third party software too. For example Librewolf AUR packages are listed on the official Librewolf project website and the gitlab for the project, sometimes the developers themselves are the ones who made the PKGBUILD script on the AUR.

In terms of inspecting the PKGBUILD files I review the full thing every time I install new software for the first time, which doesn’t take long as they are mostly simple and short. And once the software is installed on the system, this quick check for differences is all I do with the package which is usually less than 15-20 seconds, everything else above this paragraph is mostly before installing a new package on your system. In terms of whether the AUR has been made more secure or streamlined, I can’t say as I have only been using Linux since June last year, but I assume it was always set up like this.

There is also this guide from Kresimir. I am linking this as it goes in to more details regarding, potential malicious commands to look for in PKGBUILDS.

6 Likes
8

Don’t know how many “experts” get involved in NixOS’s vetting process, but the depth and breadth of the AUR’s highly knowledgeable user base (i.e., a large number of sophisticated users looking at packages/diffs to confirm what’s what) feels far more reliable to me as a security shield.

Consider: Microsoft has a well-paid tech team scouring for security holes… and yet look at all the security patches needed to plug such holes over the decades … i.e., once they’re even identified.

So, one would think the resources MSFT invests in vetting would far outstrip whatever NixOS could deploy … but yet even this hasn’t prevented Windows from security leaks through all kinds of holes.

How often/serious a breach has been found through heavily used and long-lived AUR packages? Sure, there’s some scruff there … but a little pre-download common sense investigation goes a long way.

In short: Pick your poison.

Personally I rely on the deep bench of AUR users (along with my own due diligence) as the better choice for security. YMMV. :vulcan_salute:

[p.s. - Thanks for raising this important topic once again. It’s a perennial and deserves a fresh look from time to time.]

[p.p.s.- I have tried to use NixOS and for some reason I kept hitting a wall and couldn’t get some needed PEBCAK hand holding. The EOS community, on the other hand, has made it fairly painless for me whenever I’ve stubbed a toe.]

5 Likes
9

Um, I’m gonna have to press “doubt” on this one. I’m not saying that what you are saying is outright wrong, but rather that this in and of itself gives me a bit of doubt given what I know of nix.

To my knowledge, one of the strong points that nixpkgs boasts is there rather large official repository. The way they achieve this is because anyone can contribute. I’m assuming that only relatively few people can review. Which is what leads to the many threads I have seen about the slow process to get a PR merged.

This makes me question the quality of the review. Would this not lead to exponentially more packages to review than what maintainers are able to handle?

Furthermore what is the process to become a reviewer? I’m genuinely asking because I hadn’t found the answer after a few minutes of searching. Adding more reviewers would of course be the natural solution to my previous point. However that once again should lead one to question how good random new person is at reviewing?

Another thing to point out is that the large number of packages is only possible due to the heavy and in my opinion impressive levels of automation that they have achieved. However, this also can lead to lower quality packages. Surely, not all of these are actually being looked at that closely?

On some of the threads I have seen on the nixos forums about being a reviewer. It seems that the process is no different than what the AUR asks the user to do. So at most, it simply says that at least one person has done that, so that you don’t have to.

My point is with all of this is that I feel like in a lot of cases people try to take a lot of the complexity away from a process. Whether it be with technology or some other thing is irrelevant. In many cases, this is a good thing. In others, it is but a facade. Leading people to believe that they are safer than what they are.

All that is to say, most of the time, I trust the quality of my review more than any third party. I think it is important that people not let themselves build themselves up on a house of cards trusting that everything underneath them is controlled by some higher power. In this case higher power being “good reviewers”.

Once again, I would just like to reiterate that I’m not saying you are wrong, but rather to start a conversation regarding whether or not such a system is any more secure than any of the others out there. Especially given the sheer amount of packages they have to look at.

3 Likes
10
  1. Yes. I’m no expert in the pkgbuilds but I know enough to spot red flags.
  2. It’s fine and I inspect the pkgbuild.
  3. I’m pretty new to Arch so I don’t know how it used to be.
11

AUR is a last resort for when you can find what you want from the repos, Flatpak, Snap, Appimage, etc…

12

I read this PKGBUILD and one question jumps in my mind. When using a PKGBUILD from AUR to build a package locally, don’t you need to trust the code from the developer hosted on some site? If you can read and understand the code, that is good. If you don’t know that, you have to trust. “Trusting yourself to verify the PKGBUILD” is not enough to my mind. Am I wrong?

13

Ultimately you have to trust somebody but you can make sure that it’s coming from the official repo and no dodgy patches are applied.

1 Like
14

Yes. That the least you can do but you have to trust that the code from the developer from the official repo is good.
I am not sure for a person who doesn’t know reading code, if the model from Nix packages that is somehow checked is better or checking the PKGBUILD and know it is correct but build the package from a code you have to trust that is good but you can not verify yourself.

15

This is true for every piece of Software out there that you do not put in binary yourself.

1 Like
16

Everything on my system runs on trust :sweat_smile:

17

You always need to trust the application you are installing.

It doesn’t matter where you install it from. The official repos , nixpkgs, AUR or anywhere else.

Packagers don’t review the entirety of the application source, they just ensure it is properly packaged.

This is true of all software though on any operating system. If you don’t trust the software, don’t install it.

1 Like
18

The thing is I don’t find the way how to trust them at the first place. I don’t know reading code from a software developer X to trust his software Y. For example I have to trust Archlinux at least to install their system and some applications from their repository but that is not a trust based on verification. I think this is valid for a large number of persons.

19

Checking the AUR PKGBUILD is easy and not time consuming.

Reading the entire source code for every application you install is completely impractical even if you are very skilled. Nobody is doing this.

4 Likes
20

I appreciate your perspective and the skepticism regarding my previous statement. To clarify, I want to outline the key differences between NixOS/Nixpkgs and Arch/AUR, as they operate under distinct philosophies and methodologies.

Arch maintains an official repository where the development team oversees package management. While they are responsible for these packages, it does not mean they review or audit the source code of each package in-depth. Their role primarily involves ensuring that packages build and function as expected, which enables Arch to maintain its rolling-release model. The Arch User Repository (AUR), on the other hand, is entirely community-driven and lacks official oversight from Arch developers. This means that users must manually review PKGBUILD scripts before installing software, as there is no centralized review process for AUR submissions.

NixOS follows a different approach. Any user can submit a package to Nixpkgs, but before it is merged into the official repository, it must go through a review process. This process ensures that no malicious or unintended modifications are introduced in the package definition. While this does not involve auditing the original source code of every package, it does ensure that the Nix expressions defining how packages are built are reviewed before becoming available to users. This is similar to how Debian or Arch developers handle official repositories.

If there is doubt regarding the vetting process in Nixpkgs, the same skepticism should apply to official Arch and Debian repositories, as they operate under similar principles. The main difference is that the review process in Nixpkgs results in a larger backlog due to the number of packages requiring review, which can lead to delays. However, the NixOS community has been expanding rapidly, and the number of contributors involved in reviewing packages continues to grow. Typically, multiple reviewers assess a package submission before it is merged.

Since the question was raised about how one becomes a reviewer in Nixpkgs, it is worth explaining the process. Becoming a reviewer is not something that happens arbitrarily. It is a community-driven process that requires a strong track record of high-quality pull requests and active contributions. Those who consistently demonstrate competence and involvement in the community may eventually be invited to become a reviewer. However, a new reviewer does not have independent approval power over packages. Pull requests, especially for new or complex packages, are usually reviewed by multiple experienced maintainers before being merged.

In addition to human reviewers, Nixpkgs has automated systems that perform various checks on package submissions. These include tools like Hydra, which ensures that packages build correctly across multiple architectures, and ofBorg, which runs automated linting and formatting checks. This multi-layered approach significantly reduces the risk of malicious or faulty packages making it into the repository. The NixOS community has put substantial safeguards in place to prevent exploits, and they do not rely on a single point of failure for package approvals.

Ultimately, this is not about whether NixOS or Arch is superior, but about understanding the trade-offs. Nixpkgs provides a level of assurance that AUR does not, as not all Arch users manually review AUR packages before installation. While experienced users may inspect PKGBUILDs, many others install AUR packages without verifying them. In contrast, Nixpkgs ensures that all packages in its official repository undergo a structured review process, significantly minimizing the chances of malicious code making its way to users.

I can see the validity in both perspectives shared in the discussion. Verifying packages independently offers a certain peace of mind, while relying on a team of experienced contributors, similar to distro developers, who hold each other accountable and operate with transparent mechanisms to maintain trust is equally valid. Ultimately, it comes down to which approach aligns best with the individual user’s preference.

Thanks again for sharing your thoughts.

4 Likes