For whatever reason, I’ve ignored the warning below and some given by the experts here, because some packages are maintained on the AUR by the actual developers (that’s the reason, duh). But finding out that any user can upload a package to the AUR is frightening.
I thought it was reserved to people with a good track record.
I’m going to start building/downloading/using more packages from source, AND start using fewer packages not available in the official repos or are not maintained by the actual developer.
So, eventually, paru, pikaur, yay, and dk window manager will be the only AUR packages I have on my system. Actually, my pikaur is a git package built from source already.
Hee hee, in the old days, we downloaded source code tars, extracted them, configured (and maybe did a bit of portage as necessary to build) them, and compiled them.
Old school Haven’t had to mess with portage in years, because everything is already done for Linux now (versus requiring tweaks to compile on AIX or Solaris back in the day).
Ahh…if you only have one actual AUR package you probably don’t need to have 3 AUR helpers.
That being said, AUR is one of the safest 3rd party repos out there as long as you review the PKGBUILDs and yay and paru make it really easy to do that.
Unless these are packages that live in complete isolation in your home directory, you should make sure you build PKGBUILDs for them and install them via the package manager. Of course…that is what an AUR package is.
My current setup for GIT source packages looks like this:
$HOME/Appz/GIT_PKGS/package_name
Example for pikaur:
alias gitpik="cd Appz/GIT_PKGS/pikaur/; git pull; cd"
alias gitpikup="cd Appz/GIT_PKGS/pikaur/; makepkg -fsri; cd"
And I don’t have an alias for automatically navigating to the specific directories and doing a diff check with git log -p yet, but I’ll make one eventually.
The idea is, if the AUR package is not maintained by the actual developer, then I go to the source and build from source instead.
Of course, the problem/disadvantage with this is that it takes way longer. And for some packages, like web browsers, I have no choice but to trust the AUR, because I’m not taking a whole day to build a web browser, especially since I use it for work.
“Ain’t nobody got time fo’ dat!”
Other than that, I don’t mind learning some new stuff. I just need to not overdo it.
Wait until you see how confident people are getting with installing random flatpaks (or even verified flatpaks, which can under unlikely but not impossible circumstances be even worse, due to being a more valuable target for supply chain attacks) because:
flatpak = sandbox = secure, trust me bro !!1!11!
I avoid 3rd party repos like the plague nowadays.
I really wish packaging could be the 1 non-fragmented thing about Linux, so we could all benefit from accumulated attention…
flatpak contamination my biggest fear.
AUR as well.
also SO EASY to git or wget an unvetted program…
besides undetectable hardware M/W, rogue browser extensions are a gigantic threat,
we’re probably all compromised somehow but you can’t compute in a plastic bubble…but you can try like he**
I think dispensing of the AUR is perhaps an overreaction.
For many packages, it’s entirely possible to confirm the PKGBUILD source is coming from the official repository, and that it’s legit. This is regardless of whether it’s open or closed source.
To use yay as an example, go to the AUR page, hit View PKGBUILD.
The things you need to make note of are:
depends and makedepends : some of these may be other AUR packages you’d also need to review the PKGBUILD of.
source : This is the critical one. Where is the source/binary being downloaded from. You can make sure it’s the official origin and not a dodgy fork or some other place.
sha256sums (or other sums) : This also helps you verify the source. Go to the source yourself, download the file, and confirm this sum and the sha256sum you generate, match.
Review the commands in the lower section of the PKGBUILD to ensure nothing unusual is being done. Most of these should be solely focused on organising and building a package file suitable for Arch.
Lastly, monitor diffs when updating packages for unusual changes.
Now if you’re still concerned about installing from the AUR, fair enough. But with the above steps you can at the very least download existing PKGBUILD files, verify them, then maintain them locally on your system if you so choose. You don’t have to create everything from scratch. I do this for some things, purely because I like to enable custom build optimisations and such.
Apart from checking the sums , I do everything you mentioned.
The reason for my reaction is that people like Voldemort, let’s call him that, could already exist on the AUR. So, in trying to avoid that, I’d install from source — in particular for packages that have a good enough history. I rarely install new apps, unless they are doing something that really aligns with my needs.
I have exactly 20 packages from the AUR at the moment, and for the most part, I trust them. But, I am likely to replace a few that I can build myself.
That being said: it’s not like I have some random packages installed for fun on my system apart from Steam (official repo). Most things in my AUR list are work- or workflow-related.
I’ve noted the ones I’m sure are maintained by the actual devs.
appimagelauncher
brave-bin
dk <- same dev
emote
jdownloader2
noisetorch
paru <- same dev
pix
portmaster-stub-bin
python-manimpango <- dependency for emote
redshifter <- same dev
rslsync
skypeforlinux-bin
ttf-ms-fonts
vmware-keymaps
vmware-workstation
vscodium-bin
vscodium-bin-marketplace
xnviewmp-system-libs
yay <- same dev
Gonna check the rest between now and my next update at the end of the week, then decide which ones I can build myself.
Looking at the sources now, I’m seeing that brave-bin, vscodium, and vmware can be built from source, but I’m unlikely to because they’d take forever and they have a good number or eyes on them. I wouldn’t dream of building vmware from source anyway.
That PKGBUILD is so loooooong…
I may very well misunderstood the whole process of building packages using PKGBUILDs from AUR, so bear with me.
An AUR PKGBUILD contains instructions how to build a package from some source code and how and where to install that package in the system, simply put.
In and by itself, It doesn’t do anything in the way of making sure that the source code from which the package is built is safe and secure.
The maintainer of the PKGBUILD may or may have not audited the source code to make sure that the source code from which the package is built is safe and secure.
Unless a user of an AUR PKGBUILD has audited the source code by themselves or having had it audited by some trusted other, they can not be sure that the package built from an AUR PKGBUILD is safe and secure.
In other word, AUR, regarded as a 3rd party repo, could potentially be as safe or unsafe as any other sources.
To its merit, one has to say that it makes the process of building the package transparent but beyond that I am not sure it does much more apart from a user building the package locally on their system. A package that hopefully doesn’t contain any sketchy stuff.
My understanding would echo what you say, and I think you’ve summed it up well. Perhaps a clarification on this point though:
To clarify, the AUR builds packages from either source, or binary. Essentially its task is taking either, and making them ready for use on an Arch system (which may involve compilation if from source), and then bundling that up in an installable package file.
And PKGBUILDs are only shell scripts containing instructions to build packages installable on an Arch system. The source may very well be a “source code” or a pre-built “binary” from some source code.
No matter if the source is a “source code” or a pre-built “binary” from some source code, the process of converting an AUR PKGBUILD to an installable .tar.zst is done locally on the users’s system.
Haven’t had to mess with portage in years, because everything is already done for Linux now (versus requiring tweaks to compile on AIX or Solaris back in the day).
