AUR & Chain of Trust

Hello! I just joined this forum to ask a question.

I have a question about aurla and couldn’t find a proper answer.

When you enter a site, an SSL trust chain is formed. Pacman is similar in this way. The hash values of the packages and the gpg signature values are stored on the server with Arch’s official signatures. When Pacman synchronizes or downloads packages, it relies on this trust chain. If the GPG keys and hash values on the server are changed (or if CA is compromised/SSL is forgotten), Pacman will not trust the changed signatures and hashes. Even if there is no encryption between servers, it ensures that packages are verified and downloaded securely, and essentially there is no other layer between developers.

What about AUR? When we pull a pkgbuild or something else from AUR using the AUR helper, is the trust chain preserved with Arch’s signatures? If AUR doesn’t have this, I’ll have to manually check the signatures on every installation.

Thanks

It is a bit more complicated than that because there are two or more separate things that are happening.

  1. The AUR package, which is usually not the actual program but instructions on how to build it, is downloaded from the AUR. This is done by your AUR helper.
  2. The actual software is generally downloaded directly from the source and not from AUR.

For #1, I would need to look into it to give an answer on what, if anything, is happening there. But speaking generally, they are being cloned from a git repo. I am not sure there is any verification beyond what git provides.

For #2, it is slightly more clear. The PKGBUILD itself contains instructions on how to validate the source. There are multiple options here. It can be verified with a hash, with a GPG/PGP key or not validated at all. This can clearly be viewed in the PKGBUILD and is one of the many reasons you should have your AUR helper configured to show you diffs during install and updates.

2 Likes

No, I understand aur and pkgbuilds.

What I mean is, is there any verification other than SSL security for these pkgbuild files obtained from aur?

If it were HTTP, would it still be as secure as the main Arch repository? That’s my question. Arch will be secure because the GPG signatures and hashes on the server are signed by the developers, and the servers themselves are also signed, and Pacman is always tied to the trust chain.

I understand that the hash or GPG verification within the pkgbuilds depends on the person publishing them. What I mean is, are these pkgbuilds verified?

I mistranslated the last part.

The pkgbuild itself, for example, librewolf.

If the Librewolf package is downloaded and added to pkgbuild, I understand that the hash and signature will be verified. There is no issue with that.

But what about this pkgbuild file? Is this file just trusted? Or is there a chain like pacman?

As far as I know, the only thing is the TLS from the git clone. But, to be honest, I have not investigated it deeply.

However, the mitigating control for this is reviewing the diffs. When you are reviewing the diffs, you are doing that against your local copy so you should see any problems that would arise from a MitM attack.

Hello,

The integrity of the data is ensured through git, it’s a git clone https://aur.archlinux.org/package_name.git, but the content of the PKGBUILD is not to be trusted, you must check what’s inside.

Is a man in the middle attack the sort of thing you’re alluding to here? Where you go to install what is in truth a legitimate AUR package, but a malicious actor via something like DNS interception, presents your system with a compromised version?

If using say yay to install packages from the AUR, it is configured to always use https:// protocol (see here and here) and as @vazicebon has mentioned, a git clone is used internally by yay (here) when installing a package (yay -S some package).

Git will fail if it encounters an invalid security certificate, as would be the case in a man in the middle attack.

In that way, you can generally trust that if you didn’t encounter a certificate error, the PKGBUILD came from its legitimate source.

3 Likes