Climbing the PKGBUILD learning curve 🤔

[ArchieLinux]

TL;DR Got tips on specifics to be on the lookout for when scrutinizing a PKGBUILD script?

= = = = = = = = = = = = =

In reaction to the malicious AUR package news, deeper dives into PKGBUILD scripts become ever more imperative. I’ve often previewed PKGBUILDs before installing a new app, but confess that too much of what I’m reviewing goes over my head, leaving me feeling ill-prepared.

So instead, I’ve primarily been relying upon things like: the age of the app, # of contributors, responsiveness to PRs and open issues, star ratings, and the like. In other words, I’ve relied upon “social” screening rather than “technical” screening.

Having read through Arch and EOS wikis several times over the years (and google’d around a bit) it’s hard to find summary top-level explanations as to spotting specific things within the PKGBUILD scripts that ought to be of concern.

Anyone got sources/links worth reading to get smarter about this topic?

[dalto]

This is a good start:

AUR PKGBUILDs

The AUR is one of the safest ways to install software, just because it is so transparent. But it does not tolerate just looking up the package in Pamac and clicking on the Build button, or doing yay package_name blindly. It requires that the user knows what’s going on. That’s why I recommend trying to build at least one package manually, to understand what’s going on, before using an AUR helper like pamac or yay. yay has a nice feature that allows you to inspect a PKGBUILD file before installin…

Also, it is worth noting while there are complicated PKGBUILDs out there, most of them are very simple.

The number one thing you should be doing is checking everything in the source array.

Also, if any of the dependencies are other AUR packages, you need to check those too.