Reviewing AUR upgrades (regarding security)

starch2021 · 2021-07-23 14:17:15

I'm using yay for AUR packages and wanted to know more about the review for AUR packages, particularly because some like bitwarden are security-critical applications.

I had a closer look at the files coming with the first original installation of AUR packages, and based in trusting yay and makepkg/PKGBUILD.

Now when I upgrade via

yay -Syu

I'm getting asked whether I wanna check the diffs, which seems to be related only to the PKGBUILD files.

My first question

I have e.g. the following output for bitwarden-bin:

diff --git /home/<user>/.cache/yay/bitwarden-bin/PKGBUILD /home/<user>/.cache/yay/bitwarden-bin/PKGBUILD
      new file mode 100644

So the diff command uses twice the same file which results in a diff with only "new lines". I'd expect a previous used file and a new file, which would make the review much easier due to a smaller "diff".
Is there something wrong with yay or my configuration?

Second question

If I verify that, (in the PKGBUILD files) the statements for url=... and source=... are okay, is this enough to make sure that yay will install proper AUR packages, because I'll only receive binaries or source code from URLs I decided to trust?

Or is there more to be considered, i.e. even with well-formed url=... and source=..., yay could be tricked into introducing malicious sources/binaries from other sources?

Alad · 2021-07-23 19:25:37

So the diff command uses twice the same file which results in a diff with only "new lines". I'd expect a previous used file and a new file, which would make the review much easier due to a smaller "diff".
Is there something wrong with yay or my configuration?

You might have that if the file was not present before.

If I verify that, (in the PKGBUILD files) the statements for url=... and source=... are okay, is this enough to make sure that yay will install proper AUR packages, because I'll only receive binaries or source code from URLs I decided to trust?

You realize that yay runs makepkg after showing you the diff, right? What you describe implies that yay shows you one pkgbuild, and then passes a different one to makepkg for the build process. Yay has a fair collection of bugs, but that scenario is pretty unlikely.

Last edited by Alad (2021-07-23 19:25:51)

seth · 2021-07-23 20:45:03

Consider using aurutils instead of yay wrote:

You realize that yay runs makepkg after showing you the diff, right?

Those might be distinct incidents/consideations, though.

could be tricked into introducing malicious sources/binaries from other sources

https://en.wikipedia.org/wiki/Man-in-the-middle_attack - you'd want those sources to be signed by a trusted key

Trilby · 2021-07-23 21:07:03

starch2021 wrote:

yay could be tricked into introducing malicious sources/binaries from other sources?

Who knows what yay could do. But makepkg quite easily can be. It used to be accepted practice to manually download VCS code in the prepare function. This is no longer necessary nor the accepted practice (for most VCS's at least), but the prepare function could retrieve / modify code or binaries from anywhere, regardless of what is in the 'source' array. I'm pretty sure nearly any other part of a PKGBUILD could do this too. So, no, checking the urls in the source array does not provide any security at all; you need to review and understand the full PKGBUILD.

As for the 'url' field in the PKGBUILD, that is completely irrelevant. That is not used in any way in compiling or otherwise generating the binaries included in the package (unless referenced as a variable in the source array). That is just used to display a url in `pacman -Qi` output. One could fill the 'url' field in a PKGBUILD with complete gibberish, and it'd have no real effect on anything (other than inappropriately filling -Qi output with gibberish).

Last edited by Trilby (2021-07-23 21:07:39)

starch2021 · 2021-07-24 08:14:06

You might have that if the file was not present before.

This happens always, with all the AUR packages that have been installed before upgrading already. Anyone else having this experience with yay?

You realize that yay runs makepkg after showing you the diff, right?

Well, that's what I assumed and what I wanted to make sure with this post (especially that it doesn't do anything else which could be problematic).

you'd want those sources to be signed by a trusted key

Hm, that's the next step then, but obviously that's correct.
Is there a system in place with yay/AUR to check signatures and have a trusted list of keys?

Who knows what yay could do. But makepkg quite easily can be.

Okay, but the URL for downloading malicious stuff in the prepare function would still have to be somewhere in the PKGBUILD file, right?
Anyway, this post is based on the premise that I trust yay and makepkg.

seth · 2021-07-24 11:45:00

Is there a system in place with yay/AUR to check signatures and have a trusted list of keys?

"man 5 PKGBUILD", look for "validpgpkeys"

Trilby · 2021-07-24 12:34:32

starch2021 wrote:

Okay, but the URL for downloading malicious stuff in the prepare function would still have to be somewhere in the PKGBUILD file, right?

In some form yes. But if it is indeed malicious, it might not look anything like a url. But your question is whether looking at the two fields of 'url' and 'source' would be sufficient. The answer is absolutely not, you need to look over the entire PKGBUILD and understand what it is doing.

starch2021 wrote:

Anyway, this post is based on the premise that I trust yay and makepkg.

Trust is not a binary. You trust these tools to do what precisely? I trust makepkg to not introduce anything malicious that was not already in the PKGBUILD. But I don't trust makepkg at all for finding potential malicious code in a PKGBUILD and stopping it from doing something horrible to my system. I don't trust makepkg to do this as it is not really designed to do this. As for yay, I wouldn't trust it as far as I can spell it ... and that only takes three key strokes.

FWIW, it'd be trivially easy to write a pkgbuild with no url to any malicious source that would delete all content in your user's home directory. It is also trivially easy to have malicious code hosted at a url that looks "legitimate".

Reading and understanding the full PKGBUILD (not some poorly and erroneously generated diff) goes a very long way to ensuring a reasonable degree of security. But there is no shortcut of specific fields to look at that will get you any security at all.

Last edited by Trilby (2021-07-24 12:38:00)

starch2021 · 2021-08-08 18:54:30

Trilby wrote:

Trust is not a binary. You trust these tools to do what precisely?

Yes, of course I understand the difference between official Arch repositories and AUR repositories, and the ramifications of AUR packages which are not part of the official distribution.
And of course I don't expect makepkg to protect my system against malicious code being introduced via PKGBUILDs from untrustworthy sources.

I trust that makepkg is not "malicious" because it's part of the official Arch repositories.

yay obviously is another story, but it's open source and has some level of trust due to the process of becoming an Arch package maintainer.

So I trust yay and makepkg to not download malicious (or any) code from random places which are not mentioned in the requested AUR repositories, and like most things regarding security, it's a tradeoff between usability and security.

pacman / makepkg and signatures

seth wrote:

"man 5 PKGBUILD", look for "validpgpkeys"

Thanks for the hint.

None of my AUR-packages use this validpgpkeys option. Which means (imho) that the original signatures from the Arch keyring would be used, but the AUR repos I'm using do not provide any signatures anyway.

I'm not sure why pacman can install those packages in the first place...
/etc/pacman.conf uses

  SigLevel = Required DatabaseOptional

so I'd expect pacman to refuse installation of packages without signatures.

If I build a package locally with makepkg from an AUR repo, where would the signature for pacman come from anyway...?

I had a look at the local packages in /var/cache/pacman/pkg/, but while there are 2460 files in that folder, there are only 158 signatures...i.e. many packages do not have signatures at all...

Also the databases seem to come without signatures:

  /var/lib/pacman/sync/community.db
  /var/lib/pacman/sync/extra.db
  /var/lib/pacman/sync/core.db

How is it possible that pacman installs those packages without complaining about missing signatures?

AUR / yay

For everything installed via AUR repositories, it's apparently more tricky than I first assumed. I understand that I'd need to consider two things:

the PKGBUILD content of the AUR repos. There's some level of trust due to Arch's process for appointing AUR package maintainers. Signatures for the PKGBUILD could be used, but it seems they are not used very frequently
the source code/binaries mentioned in the PKGBUILD files of the AUR repositories, which are eventually downloaded via "makepkg". There are obviously no signatures that could be used for those "third-party" repositories

So far I mostly check

the source entries in the PKGBUILD. I'm fine if it's e.g. a Microsoft repository for "MS Teams", or an official Bitwarden website for the download of the binaries
the rest of the PKGBUILD files for anything that looks suspicious

Finally, I try to use as few AUR packages as possible.

I still would like to understand why yay doesn't provide proper diffs (which would make reviewing much easier).

seth · 2021-08-08 19:56:17

If I build a package locally with makepkg from an AUR repo, where would the signature for pacman come from anyway...?

man makepkg.conf, look for GPGKEY

How is it possible that pacman installs those packages without complaining about missing signatures?

man pacman.conf, LocalFileSigLevel - then check your pacman.conf…

I still would like to understand why yay doesn't provide proper diffs (which would make reviewing much easier).

The parrot inspector wrote:

Who knows what yay could do. … poorly and erroneously generated diff

Alad · 2021-08-08 20:07:24

yay obviously is another story, but it's open source and has some level of trust due to the process of becoming an Arch package maintainer.

How does yay and "the process of becoming an Arch package maintainer" relate? Anyone can upload something to AUR - that doesn't mean it's "trusted". Sure, it might be popular - but so was say, acroread, which was compromised shortly after being orphaned by its maintainer.

Which means (imho) that the original signatures from the Arch keyring would be used, but the AUR repos I'm using do not provide any signatures anyway.

No. validpgpkeys uses the user keyring, which is separate from the Arch keyring. See http://allanmcrae.com/2015/01/two-pgp-k … rch-linux/

Also the databases seem to come without signatures:

Databases are not signed, packages are. There's some difficulties involved in former, e.g. deciding who should sign databases, or where private keys should be stored.

There's some level of trust due to Arch's process for appointing AUR package maintainers.

No. There is no trust whatsoever. Anyone can register. Anyone can upload PKGBUILDs. That's why the website says, in bold: DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk. .

Signatures for the PKGBUILD could be used, but it seems they are not used very frequently

PKGBUILDs themselves are not signed. The signatures are for whatever source archives makepkg retrieves.

I still would like to understand why yay doesn't provide proper diffs (which would make reviewing much easier).

None of the pacman wrappers thought about making reviews easy. They simply copied the process from yaourt, which showed the PKGBUILD of each package before building it. Then someone mentioned git diff, so they dropped in the command without thinking where or how it could improve things.

Last edited by Alad (2021-08-08 20:11:49)

Arch Linux

#1 2021-07-23 14:17:15

Reviewing AUR upgrades (regarding security)

#2 2021-07-23 19:25:37

Re: Reviewing AUR upgrades (regarding security)

#3 2021-07-23 20:45:03

Re: Reviewing AUR upgrades (regarding security)

#4 2021-07-23 21:07:03

Re: Reviewing AUR upgrades (regarding security)

#5 2021-07-24 08:14:06

Re: Reviewing AUR upgrades (regarding security)

#6 2021-07-24 11:45:00

Re: Reviewing AUR upgrades (regarding security)

#7 2021-07-24 12:34:32

Re: Reviewing AUR upgrades (regarding security)

#8 2021-08-08 18:54:30

Re: Reviewing AUR upgrades (regarding security)

#9 2021-08-08 19:56:17

Re: Reviewing AUR upgrades (regarding security)

#10 2021-08-08 20:07:24

Re: Reviewing AUR upgrades (regarding security)

Board footer