You are not logged in.
Pages: 1
So out of curiosity I googled (my google is biased and knows that I'm not just starting linux) for "AUR for dummies" to get an idea what people under ideal circumstances will read when ignoring the wiki.
The results, blogs and videos, all wanna make you puke ![]()
In the assistance box there was, next to "Does Elon Musk use linux"… ![]()
"What are the risks of using the AUR?".
Opening that I got
In practice, the risk in the Arch Linux AUR is structural. It comes from how it works, not from a few bad actors.
AUR packages are build scripts. They are not vetted binaries signed by a central authority.
and a link to this article which is not exactly for dummies, but the one you want are going to read!
nb. this is not an advert for the tool discussed in the article, but I'll stress that here
But there are limits. Pattern-based analysis can flag obvious red flags, yet it does not understand intent. A legitimate package might fetch additional resources during build. A complex but safe PKGBUILD might look noisy. You will see false positives. You will also see clean reports that still deserve human review.
This is where people get it wrong. They treat scanner output as a verdict instead of input.
Edit: because there's a reddit thread pointing out homograph attacks
cat PKGBUILD | tr -cd '[:print:][:cntrl:]' | vimnb. this exploits a deficit in tr (handling wide characters, they'll be deleted by this) and there might cease to function w/ updates adding this ability to tr.
@mods, I know the rules about PSAs but the content article exceeds the scope of the wiki and we also cannot just copy it anyway and just linking it there will unlikely raise its visibility and the other threads have shown broad misconceptions about the AUR that need to be addressed.
If you've a reddit account, spread it there.
Last edited by seth (2026-06-17 19:29:45)
Offline
Moderator Note
Mods are discussing what to do with this info .
For now it can stay here.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
The reddit thread was this: https://www.reddit.com/r/archlinux/comm … _paru_yay/
Homograph attacks: https://en.wikipedia.org/wiki/IDN_homograph_attack
Tools like traur shine when they deliver true positives and traur specifically delivers a score that is mostly up to you to interpret. At this point, any sort of advisory will be pretty useless, because those attacks do not target IT professionals who are capable of analyzing threats, but the huge number of "fire and forget" AUR users from the various categories spanning from "Tired of Winows 11, should I install Arch?" to users of Arch derived distros that are compatible enough to use the AUR with one of the popular helpers.
Offline
I do not quite understand the problem with looking at `diff`s. Obviously, in some cases, there isn't enough context. But in lots of cases, the changes are simple and routine?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Obviously, in some cases, there isn't enough context.
We're probably looking at the upper end of shenanigans when talking about the injection of lines into code that in isolation look harmless enough but together AND OVER TIME will form a new routine and the author also doesn't express how exactly she views or expects her audience to view diffs ("If you review diffs but do not expand every function", obviously a minimal diff w/o context and functions and only line numbers is more confusing than a pru)
The wiki btw. hints at using vimdiff because of this, https://wiki.archlinux.org/title/Arch_U … e_PKGBUILD
In reality™ you check the log, then you look at the diff since your last build (using git tags helps with that) and you look at a function in its new form if you stumble over something irritating™ in the diff - keep the "over time" aspect in mind.
If the diff only changes the version and the checksum (ie. the reason why you're rebuilding the package itfp) you don't have to scrutinize anything extra.
The homograph attack btw. caught me semi-off-guard.
The way my terminal is set up, it doesn't work in urls (because they're italic and then the cyrillic glyph sticks out) but that's of course coincidental and I have reviewed (and edited) PKGBUILDs in sqriptor which does not uglify wrong languages so I just afforded it a check for non ascii glyphs when opening a PKGBUILD (and a warning dialog)
Offline
The structural risk in AUR is real but often overstated. AUR is a build script repository, not a package repository. The distinction matters.
The actual risk vector is not malicious packages (those get flagged and removed quickly by the community). The risk is outdated build scripts that pull in vulnerable dependencies or break against newer system libraries.
Practical mitigation:
1. Check the last updated date. If a package has not been updated in over a year, treat it as abandoned.
2. Read the PKGBUILD before installing. Always. If you cannot read a PKGBUILD, you should not be using AUR.
3. Check the maintainer. Active maintainers with good standing are a signal.
4. Use makepkg directly instead of AUR helpers that auto-fetch and build without review.
The blog posts and videos that seth mentioned are indeed terrible. Most of them teach cargo-cult usage of yay without explaining what makepkg does or why reading the PKGBUILD matters.
The wiki is the correct source. Always has been.
Offline
Check the last updated date. If a package has not been updated in over a year, treat it as abandoned.
No. What if the upstream is slow?
If you cannot read a PKGBUILD, you should not be using AUR.
You can use. But you shouldn't Rant on support forums if smtg goes wrong under ur responsibility.
Check the maintainer. Active maintainers with good standing are a signal.
Metadata can lie. eg. maintainer's account compromised or the maintainer is/was a sleeper account.
Use makepkg directly instead of AUR helpers that auto-fetch and build without review.
using helper or building manually, if PKGBUILD is shady, you are cooked.
Offline
Manually installing packages from AUR makes you not want to use it, which is a good thing.
Offline
Thank you, seth. This is very useful info. I wasn't aware of homograph attacks/punycode.
BTW I often use set encoding=latin1 inside vim when editing code to prevent any non-ascii.
Last edited by topcat01 (Yesterday 20:52:01)
Offline
Pages: 1