TL;DR: Don’t think of the AUR as a package source, but as of an only mildly moderated, but ultimately free and open, sharing platform for PKGBUILDs, primarily useful for (self-)packagers, not necessarily non-technical end users.
Before the AUR, you had people individually hosting their PKGBUILDs anywhere, sometimes on GitHub or the BBS (yeah, it’s been a while), sometimes along with a repository URL you could add to your
pacman.confto install packages right away, and it was glorious. I didn’t have to write a working PKGBUILD myself from scratch, and I could decide if I trusted that particular packager to not screw me sideways with a pre-built package. An officialized “Trusted User” (TU) role emerged from this idea, which has recently been renamed to Package Maintainer (PM). This is fundamentally still how the AUR works, it just became much bigger, and easier to search for particular software. Packagers gift to you their idea of how software should be packaged, for you to expand upon, take inspiration from, or learn, or use as-is if you determine it to be good for your purpose.The AUR is ultimately a great resource for packagers, and still useful for users, but “true end users” get the
extrarepository, andcommunity, kind of, before that, and should try to avoid the AUR if they can, or at least be prepared to put in effort to establish trust, or get help.A handful of Package Maintainers are manually adopting and subsequently vetting for sufficiently popular packages to move them from the AUR to the official
extrarepository, which is deemed safe to use as-is, on a best-effort basis. Obviously, this is a bottleneck, as it is not feasible for the few volunteering PMs to adopt and maintain 10k+ AUR packages and be held to any quality standard. That’s why “you are on your own” with the AUR.On the positive side, there’s a voting system to determine package popularity. AUR packagers have a public list of maintained packages, and a comprehensive git commit history. Establishing trust is still crucial, and I feel hard pressed to name a reasonably popular/useful package that isn’t already in
extraor has been maintained in the AUR for a long time.The biggest risk, IMHO, for malware getting slipped into a package is orphaning a popular package, and having it adopted by a malevolent user. This is something I personally look out for. If the maintainer changed, I make sure to check the commit history to see what they did. Most of the time it’s genuine fixes, but if anything is changed without a damn good and obvious reason, hit up the AUR mods and ask for help. This is how malware is spotted. Also, typically only the version is bumped in a PKGBUILD on an update, which is a change I feel safe waving through, too. If the download URI changes, or patches are added, I do look at them to determine the reason, and if that isn’t explained well enough to understand, that’s a red flag. Better ask someone before running this.
source: personal involvement in Arch since 2002
I use NixOS so everything is second party
And every package is added and maintained by volunteers.
We’re called maintainers
Most maintainers are volunteers, but not all volunteers are maintainers…
Besides the obvious non-package work, if you make a single pr for some random package and never again, you’re not a maintainer.
The Nix ecosystem is developed by many volunteers and a few paid developers, maintaining one of the largest open source software distributions in the world.
demanding work that we cannot expect to be done by volunteers indefinitely.
Meanwhile me who using CHAOTIC-AUR be like :
As someone not too familiar with arch and not undertanding the full context, could you elaborate on how Chatoitc AUR differs from AUR?
TLDR EXPLANATION:
Basically Chaotic AUR is just AUR that has been compiled so user doesn’t have to wait for a package to install.LONGER EXPLANATION:
Chaotic-AUR is an unofficial package repository that provides pre-built packages from the Arch User Repository (AUR), allowing users to install software without building it from source. In contrast, the AUR requires users to compile packages themselves, offering a wider range of community-maintained software but requiring more technical knowledge and time.In contrast Chaotic AUR offered simpled way to install AUR packages, Chaotic AUR packages already cleaned from malware, spyware, etc so there’s no need to worry.
I smell something fishy going on. I’ve been using the AUR for a long time and I’m now just hearing of malware?
There’s been malware in the past, not only that - AUR is user submitted. It’s in the name. They warn you to double check what you’re installing. It is functionally similar to running a random installer you found on GitHub.
It seems like these instances are being intentionally blown out of proportion, but I don’t see what there is to gain by doing that.
I don’t want to say stupid things, but I have so many theories. I check the shit out of a package before installing it. I even go to the GitHub page and make sure of things.
Ðis is ðe only way. Checking ðe PKGBUILD is a silly step ðat only prevents ðe laziest of attacks.
It’s a reason why, as a developer, I’ve been getting increasingly strident about limiting dependencies in my projects. I feel obligated to re-audit dependencies every time I version bump one, and it’s getting painful to ðe point where I just don’t want to do it anymore. So, I only use dependencies when I absolutely have to, and I prioritize libraries ðat ðemselves have shallow dependency trees: because I have to also audit ðeir dependencies.
Ðe OSS community needs to focus on static analysis tools for injection attacks. Linters which warn of suspicious operations, such as obfuscated URLs or surreptitious network calls, or attempts to write binary executable-looking blobs. Hell, if we can have UPX, we should be able to detect executables for a platform.
Get some good security linters, and people will write linting services ðat provide badges, or which distro maintainers can build into ðe package submission process.
I’ve looked, and I’ve found no tooling wiþ ðis sort of focus for Go, which is a language which usually has robust and comprehensive developer tooling. Ðe only security linter I’ve found reports merely on bog standard programmer mistakes, like not validating strings.
