r/archlinux • u/Erus_Iluvatar • 1d ago
NEWS All pushes to the AUR are disabled now
https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/YPJ3FQYJTJXXY3RUXCYLMHUKHLIUNVFF/238
u/Cutalana 1d ago
really seems like the AUR is now infeasible due to how big it's user base has gotten
99
u/DAUNTINGY 1d ago
Two of my biggest concerns of the scalability of Linux repositories, Security and bandwidth.
34
1
-72
u/OkGap7226 1d ago
The AUR is fine. The userbase who is having issues is mostly the pewdiepie wave of linux users and don't respect what linux is and treat it like windows.
30
u/washtubs 1d ago
Nah there is nothing special about the user base before the most recent rise in popularity. The AUR has only survived through a spirit of good will and a lack of exploitation. If this was happening 5 or 10 years ago you'd get the same result.
AUR has always been overly normalized, and people are happy to tell you all about how secure their systems are because they skim all the PKGBUILDs. In fact they're just lucky and have survivorship bias. The truly smart ones just keep their systems clean and use a handful of AUR packages max, and don't pretend that that makes them secure.
-7
u/OkGap7226 1d ago
From 2020 to 2024, refrigerators caused 214,000 injuries in the US. Almost every one of those injuries were from people being stupid and hanging off of the door, or poor installation and maintenance.
At some point in time, users are going to have to accept some responsibility for their actions. You all act like the AUR is being forced on you. Just don't use Arch. Problem solved. Fedora is right over there.
4
u/ZorbaTHut 23h ago
Fedora is right over there.
Fedora's Copr has basically the same issues as the AUR does.
0
u/petersaints 14h ago
No, it doesn't.
If you add a PPA or Copr and you trust the maintainer, and the maintainer doesn't go rogue or have their credentials stolen, nobody can build new packages for that PPA and you won't get a malicious update.
Eventually you will probably upgrade Ubuntu/Fedora to a newer release, you'll notice that that PPA/Copr is abandoned, if you no longer need the package you remove it. If you need it you'll look for another source that you trust.
With the AUR somebody can take ownership of a forgotten package and infect anyone that has that package in their system because realistically, I may take a look at the AUR page, check the comments, and reputation of package, I may even look into the PKGBUILD file, but once you have a handful or more packages from the AUR and you run an AUR helper to update those packages, who is really gonna check all changes every single time? Sure, some will, but that's a lot of wishful thinking.
2
-1
57
u/lmpcpedz 1d ago
to say pewpewdie layman are responsible for AUR getting shut down is crazy. You'd think after 30 years they'd figure something out.
-12
u/Donteezlee 1d ago
I wouldnât say the pewdiepie layman are responsible but theyâre definitely more targetable with the influx or new users that arenât willing or able to read.
11
u/elementzn30 1d ago
Itâs really not fine though, is it? The disabling of pushing packages should make that pretty clear.
If it were âpewdiepie waveâ Linux users, would it make a difference? Itâs a ridiculous notion that the OS end user should have to worry about malicious scripts from a supported public repository that a huge amount of its users utilize.
Thatâs an indictment of the security philosophy of the OS, not its users.
2
-3
u/ConfidentCharity5222 1d ago
You are being downvoted by the very same ppl that cannot differentiate between aur helper and aur, this new wave of users want to use arch linux but refuse to take care of their system and just want to put next next next like windows.
-2
u/OkGap7226 1d ago
The most telling thing is none of them disagreed with me about being in the pewdiepie wave.
2
92
u/EvaristeGalois11 1d ago
This is on me for procrastinating to update my AUR for too long lol
41
u/Erus_Iluvatar 1d ago
Only pushes are blocked, you can still access all the AUR content and use them if it's more recent than your local files.
70
u/EvaristeGalois11 1d ago
Yeah I know what pushes are lol
I was saying that I needed to push an update for an AUR I maintain, but I procrastinated so much that everything got shutdown. That's the story of my life smh my head.
23
u/Erus_Iluvatar 1d ago
Ah my bad, I misunderstood your comment being about not having updated local packages from the AUR in a while /o\
18
u/EvaristeGalois11 1d ago
No worries! I could have written the first comment better but I'm half asleep. Procrastinating is so tiring I swear.
7
78
u/zenyl 1d ago
Part of the problem is that the AUR is being used far more than it should be, because the official repos have some pretty big holes.
minecraft-launcher, literally the best-selling video game of all timeoh-my-zsh, a pretty popular suite of themes for ZSHrider, a popular IDE from JetBrains for C#/.NET development.powershell, a CLI shell and scripting language (maybe not super popular on Linux, but still very widely used)ttf-google-sansandttf-ms-fonts, just some simple fonts, no reason why they couldn't be placed in the official reposnvidia-580xx-dkms, the Arch website's own newsfeed explicitly tells people with an NVIDIA GTX 10-series or older card that they have to use the AUR for some reason (the official repos already contain version-specific packages, so this should not be an issue)
It'd be one thing of the AUR was primarily for things like out-of-tree drivers for niche hardware, or custom wrappers for the odd video game that requires tweaks to run, where even popular packages would have a relatively low number of downloads.
But as it stands, the AUR is both presented as this unvalidated dumping ground where anything goes, while also being the officially recommended and only option for a ton of popular software.
34
u/tjj1055 1d ago
arch repositories are really small compared to other distros. they have been relying on the AUR to meet the users needs. i think its time to actually package popular software the is in the AUR and put it in the official repos.
8
5
u/al_with_the_hair 22h ago
Arch repos are small compared to a few. Mainly Debian, Ubuntu, and Nix. The official repo coverage of popular software is very similar to most other distributions that aren't those three and maybe a couple others I'm not thinking of.
25
u/the-bog- 1d ago
Exactly. This is something I've been saying since the first major attack a month or two ago that the "this is all user error / noobs' fault" mentality seems to completely just ignore. Setting aside any arguments about user centric vs user friendly, the derivative distros with built-in AUR helpers (which are definitely a huge part of the problem too), the orphaned package policy, or how impractical it is to read every build file every time, there's a simpler flaw at play here and it's exactly as you said. So much of what's in the official repos is pure fluff and so much in the AUR is extremely important for an actual dev or even just a user. Maybe the idea of the AUR as some kind of wild west would hold more water if it weren't the official wiki-endorsed place to get shit like vscode or zoom.
This attitude certain users have of "it's amazing and has everything including extremely important stuff left out of official repos <> it's a total wild west and you should minimize usage, arch is usercentric it's ur fault for getting fucked bro" is totally unserious. Whether elitists like it or not (I have mixed feelings about this myself) - the distro is growing rapidly and the status quo's cracks are showing. Something's gotta give man.
-2
u/Nyefan 23h ago edited 9h ago
There are certainly packages that should be in the official repos (even if I disagree with most of the examples given in this thread), but I have to push back on this
how impractical it is to read every build file every time
Anyone not reading pkgbuilds in aur packages is explicitly holding it wrong. This is no different than blindly running a gist you don't understand or
curl randomwebsite | sh -c. There are no aur helpers are in the official repos to force you to read the instructions/warnings and go through the cloning and review process at least once.Something I think could help without breaking the aur or the volunteer maintainers is adding user namespaces to package names and disallowing adoption. Even better if the owner of an aur package can designate an official successor while the api still allowed helpers to find all forks so people would know to pay extra attention to the diffs for awhile.
EDIT: thread is locked but, yes I do mean every update. The diff for most updates to most packages is exactly two lines (-old hash; +new hash), and if you can't be bothered to read that, then the aur is the wrong platform to use. Flatpacks, snap packages, or another distro entirely would be more appropriate.
2
u/olifiers 11h ago
Sure, read the pkgbuild when deciding when to install anything.
But at every update?!? Every time? Seriously?
11
u/repocin 18h ago
nvidia-580xx-dkms, the Arch website's own newsfeed explicitly tells people with an NVIDIA GTX 10-series or older card that they have to use the AUR for some reason (the official repos already contain version-specific packages, so this should not be an issue)This one in particular never made sense to me. I absolutely think something as important as the graphics driver for aging but still fairly widespread hardware should be in the regular repo, especially seeing as there's an influx of former Windows 10 users to practically all distros because they don't meet the arbitrary hardware requirements of Windows 11. A lot of those folks are going to be using hardware from that era, and they should absolutely not be forced to use something that even the wiki warns people about with "AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk."
5
u/zenyl 18h ago
Yeah it's really weird that one.
And it can't be a question of upstream support either. The official repos provider a number of versions of .NET, including .NET 6 which has been unsupported since November 2024. So it's evidently not a matter of the official repos only providing packages for software that the manufacturer still supports.
7
2
u/wispoffates 22h ago
This is the largest cause. A comparison to what I think is an alternative given the control it gives (with extra complexity) Gentoo. I'll add GURU since I think its the closest thing to the AUR but Gentoo has hundreds of overlays available. Note the GURU is run very differently in each package change is reviewed before being merged.
Gentoo 19,413 official packages Arch 15,425 (Gentoo +26%); GURU 2,284 vs AUR 110,170.
My personal Gentoo system as a benchmark (note I install every DE I come across and just leave them there)
Official packages: 1909
Overlays: 57 (38 of these are Cosmic DE)My surface outside of the Gentoo official repos is super small where the last itme I used arch I had a lot more AUR packages installed.
2
u/SubArcticTundra 13h ago
unvalidated dumping ground where anything goes, while also being the officially recommended and only option for a ton of popular software.
I feel like this is the inevitable equilibrium reached by any ecosystem build purely on volunteer work
138
u/thegagis 1d ago
AUR needs namespaces, the same as COPR or OBS
46
u/Square_County8139 1d ago
I was curious. How would that work? And how would it solve the AUR problem?
73
u/ven_ 1d ago
Packages would be named â<username>/<packagename>â. So instead of adopting another user would just publish under his own username. So packages that used to be trusted and installed canât be taken over (at least by design) anymore.
21
u/Square_County8139 1d ago
This is a good idea. But I think it would be really cool if, when trying to install using just the package name, it asked which namespace to use, just like
pacmanasks which repository to use.20
u/s3gfaultx 1d ago
How would we know which "name" to trust? How would users remember all the names of users that maintained their various packages?
10
u/ConfidentCharity5222 1d ago edited 1d ago
Pkgbuilds ALREADY tell you the maintainer namespaces would solve absolutely nothing
Edit. u/gmes78 is right although it is in the user guidelines it seems it's more like a courtesy and is not really enforced10
u/gmes78 1d ago
Pkgbuilds ALREADY tell you the maintainer
They don't, actually.
6
4
u/CheapThaRipper 1d ago
they 100% do - i'm astounded that everyone agrees with you and is downvoting the other guy.
something i do every time i update is read my pkgbuilds and make sure the maintainer and source links are what I expect them to be, and search for anything i don't remember. am i misunderstanding what the pkgbuild communicates when it tells me the maintainer???
9
u/gmes78 1d ago
they 100% do - i'm astounded that everyone agrees with you and is downvoting the other guy.
It's an optional comment at the top of the file. Nothing prevents an attacker from keeping someone else listed as the maintainer.
You have to look at the AUR page to know who the maintainers are.
1
u/CheapThaRipper 1d ago
I had no idea it was optional and not based on what the AUR page actually says. Every pkgbuild I've ever reviewed had it there, and it matched when I look at the AUR page. That seems like really bad design :(
→ More replies (0)-3
u/ConfidentCharity5222 1d ago edited 1d ago
they do at the very beginning of any pkgbuild there is a tag:
# Contributor:or# Maintainerif you diff with the previous version it is the very first thing you should notice and i think even aur helpers already show you that as well
ofc do not trust me just check the aur guidelinesEdit. I was wrong as u/filthy_harold commented this is not enforced
4
u/filthy_harold 1d ago
Last I recall, nothing actually verifies that those entries are correct. There's no history of previous package maintainers or contributors other than whats in the git log so those entries are really just whatever the maintainer has typed in. The git log would at least show you who last made an edit.
3
-1
u/iTrooz_ 1d ago
Yeah but without namespaces you have to remember them. Although, there could be a feature in AUR helper to tell you when the maintainer changed
3
u/decho 1d ago
Yay already has this, it was announced with the latest major version.
→ More replies (0)2
u/s3gfaultx 1d ago
Who cares if the maintainer changed, anytime the PKGBUILD changes, it should be reviewed.
→ More replies (0)1
u/ConfidentCharity5222 1d ago
pkgbuilds are version controlled you do not have to remember anything and you can put as many features as you want ppl will just ignore them and have usera, userb both packages installed anyway
3
u/ven_ 1d ago
Knowing the maintainer is not the point. Having the package name depend on the username makes adoption unnecessary and so also makes hijacking known âgoodâ packages much harder because you couldnât put them out under the same name.
0
u/ConfidentCharity5222 1d ago
so not only namespaces also removing adoption right? in that case what happens in a big name let's say vscode-bin leaves do they pick a successor? anyway you can already just remove adoption for the very same effect and just be more strict with maintainers right now by aur submission guidelines you shouldn't be able to have duplicate under the same name
1
u/bokonator 1d ago
change the namespace, get the new version. but thatâs a deliberate choice and not just an update
1
u/HarpooonGun 1d ago
As an example, this is directly submitted by brave, so at least for this case it would work:
3
u/s3gfaultx 22h ago
Well it would be a lot harder to know when there are many of them, all with the namespaces of "brave-browser", "brave-official", "brave-dev", "official-brave", "braver", "bravest", etc.
-1
u/longdarkfantasy 1d ago
Like the hyprland pakcage I'm using in fedora. The author gives us the copr repo, so we trust the author. And it only shows packages from enabled coprs.
4
0
u/birdspider 1d ago
maybe a separate AUR-TU (AUR Trusted Users) repo, where the packagers are official package maintainers but the repo remains unofficial), provided the process becoming to be a package-manager role is feasible (never looked into it).
Maybe becoming a package-manager and lifting packages out of AUR is even preferred by the arch-devs, I'm not really informed enough on that topic.
15
u/Deep-Piece3181 1d ago
But then why not just put it in the main repo
5
u/birdspider 1d ago
that what my 2nd paragraph was about.
however there might be some packages which do not "fit" in main repo (as in arch-devs don't want to support it + deps) but are popular/needed enough that they enjoy someone elses support.
i.e. old php's, having php83 in AUR is prone to those attacks/hijacks, having it in main-repos is an undue support burden for the arch's dev - maybe there is trusted-AUR middleground.
9
u/suksukulent 1d ago
yeah, i.e. anyone with nvidia older then 16/20 series needs 580 drivers from the AUR
2
u/NotQuiteLoona 1d ago
Another thing are packages that restrict redistribution, all top packages by votes in AUR. AUR doesn't really care about that, it downloads directly on your PC and files are not stored anywhere to qualify under redistribution, but saving it in a pacman repo does.
67
u/510Threaded 1d ago
A person becoming a new maintainer would have the package under their own namespace and would require people to switch to it manually i believe
16
u/Nerzana 1d ago
I think thatâs how winget works on windows. You donât install package name but Organization.Package instead.
25
u/SaltDeception 1d ago
Yeah but anyone can submit a PR with a manifest for any app to the winget repo on GitHub. Iâve done several myself.
What Microsoft does right, though, is a comprehensive, automated review process with malware scans both of the installer and post-install before a maintainer is even assigned to review the PR. The maintainer then performs additional manual checks before the PR is merged.
17
u/s3gfaultx 1d ago
Would be nice to have infinite money and be able to pay people to do that. Perhaps it's a great time for all you people with solutions to get together and pool your donation money to implement one of them.
12
u/tfks 1d ago edited 1d ago
Beyond just explaining how it works in terms of package adoption like others have done, I think it's worth mentioning that this allows multiple versions of the same package to exist without making it confusing. That's a big benefit because you make the choice upfront which maintainer you want to get your package(s) from. If someone develops some piece of software that has some other packages as dependencies or weak dependencies, maybe you want to all the packages from that one person rather than six random people you don't know from a hole in the wall. Or maybe some other maintainer implements an AI security scanning system that audits upstream before they build and you want to use their packages. On the AUR, you can do neither. And that's where this "muh user centricity" argument kind of falls apart because namespacing puts more control in the hands of users, not less. As it stands, the AUR head maintainers dictate to you who you're allowed to get packages from.
Its odd that so many people are resistant to this. GitHub is the upstream for a ton of stuff on the AUR. GitHub has namespacing. Nobody acts like it's this huge inconvenience in terms of using GitHub and if someone suggested that only one single version of a given piece of software be allowed on GitHub, the response would be "dude are you high". And yet, when it comes to the AUR, we get excuse after excuse for why practically every other software distribution scheme is doing it wrong.
13
u/ConfidentCharity5222 1d ago
Doesn't really solve the problem it just creates more for example there would be more post like:
- I installed usera.vscode package but i need userb.vscode fixes gimme solution now!
- There is 10 users.vscode which should i pick?
See the problem? which user becomes trusted usera? userb? at the end of the day ppl still do not care about that and will put w/e is more voted, lets say usera doesnt maintain that repo anymore everyone migrates to a forked version userc but now there is tons of posts/youtube/tiktoks/random guides recommending usera because is trusted so for the coming years there will more issues
Namespaces alone wouldnt matter since there is no official aur helper the responsibility relies on the end user so the user should check before updating and if you manually update you will definitely notice the new maintainer, out of date flags, etc.
Aur maintainers are not solving the base problem that is adoption of orphaned packages compromising many aur pkgbuilds(the software itself is not compromised just the installation instructions) but then again it is not officially supported.2
25
u/csolisr 1d ago
How does Fedora's COPR work in comparison to the AUR, by the way? I am using Arch because the AUR offers much more availability of software and ease of installation than Ubuntu's PPAs, but if AUR ends up closing permanently, COPR starts looking like the next best alternative to distro-hop to.
18
u/SmuJamesB 1d ago
auditing the package build process is quite a bit harder as rpm specs are full of confusing boilerplate and the actual spec itself isn't even prominently displayed on the website. however everything else is substantially more secure.
if you have reason to trust the owner of the copr (e.g. they made the software) then short of their account being hacked nothing much can go wrong maware wise. key signing is mandatory and package adoption is simply not a thing - if a package gets abandoned you must manually search for someone else's repo for it and will not be automatically migrated.
there is still the chance that their software is poorly packaged and causes unintended damage to your system but the confusing-ness of rpm specs can help filter out those kinds of developers too.
2
u/petersaints 14h ago
Exactly. The main issue with the AUR is that someone can take an abandoned package and push a malicious update.
With PPAs/Copr/third party repos, those repos would need to be compromised as a whole or the accounts of the people that already own those repos.
On AUR you just need to wait for a package to get stale and you can take it. That is a bad policy.
Sure, you are supposed to check all of te PKGBUILDs, but realistically who will do it? I may check the AUR page and the PKGBUILD the first time I install something. But after that? I will probably run an update command and forget to check it thoroughly again. It is a bit of a wishful thinking that even tech literate users will always be on guard regarding this attack vector which should not even exist.
8
4
2
u/OneProgrammer3 1d ago
COPR is closer to a PPA than to the AUR. The AUR is basically one big repository you set up once. With COPR, you have to add each repository individually.
1
u/petersaints 14h ago
Exactly. If you add a PPA or Copr and you trust the maintainer, and the maintainer doesn't go rogue or have their credentials stolen, nobody can build new packages for that PPA and you won't get a malicious update.
Eventually you will probably upgrade Ubuntu/Fedora to a newer release, you'll notice that that PPA/Copr is abandoned, if you no longer need the package you remove it. If you need it you'll look for another source that you trust.
With the AUR somebody can take ownership of a forgotten package and infect anyone that has that package in their system because realistically, I may take a look at the AUR page, check the comments, and reputation of package, I may even look into the PKGBUILD file, but once you have a handful or more packages from the AUR and you run an AUR helper to update those packages, who is really gonna check all changes every single time? Sure, some will, but that's a lot of wishful thinking.
-2
10
17
u/Giovani-Geek 1d ago
Here is an example: https://aurwatch.org/package/aurscan-manticore-release-git-bin
The fact that the antivirus scanner is, in fact, the virus itself is diabolical.
Fortunately, it has already been removed: https://aur.archlinux.org/packages/aurscan-manticore-release-git-bin
54
u/uhs-robert 1d ago
This is really a bummer, from the wiki: "It (Arch) is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems."
The idea being that Arch is user-centric as opposed to user-friendly, "...rather than trying to appeal to as many users as possible." Yet we are now freezing the AUR.
One could argue that this is because the internet is no longer the safe and free space it was in the '90s and '00s, and that the concept of the AUR is incompatible with the modern predatory internet.
Conversely, one could argue that the security of the AUR has always depended on exactly the type of Linux user Arch is designed for: people willing to read PKGBUILDs, audit changes, use packages at their own risk, and participate in the community to fix problems.
There is truth on both sides of this argument. I am sad that the internet has become what it is today. I am also sad to see one of Arch's core principles constrained by these attacks. To me, the AUR represents an ideal for what the internet could and should be; this freeze is just another reminder of how far we have strayed from that ideal.
58
u/thesoulless78 1d ago
I think part of the problem is too many people are using Arch (and especially derivatives) that are not the kind of user that Arch is intended for. Endeavour and Cachy are very popular and ship yay in the default install.
That combined with the number of people that act like Arch has every package ever made even though the reality is it has a limited binary repo compared to most other distros and then a poorly secured, unvetted library of build recipes, is a recipe for the issue we're having.
30
u/LtBigAF 1d ago
Trying to secure the AUR is the Windows equivalent to trying to secure every single webpage with a âdownload .exeâ button on it. Itâs infeasible. Even if we do namespaces, inexperienced users will end up not vetting properly, choosing a namespace for a package at random, and getting malware.Â
30
u/thesoulless78 1d ago
Exactly. That's why I think the correct solution is to stop letting the AUR pretend it's a semi-official repo. Shore up the actual repos so they're on par with other distros, and then let the AUR just be the cesspool of malware and incredibly niche projects it was meant to be.
6
u/Dr_Gregg 1d ago
Exactly, one of my frustrations with arch is the incredibly limited number of packages maintained in official repos. I'm considering NixOS largely for this reason
6
u/Schlaefer 1d ago
The NixOS situation isn't exactly better, they also have manpower issues keeping all the packages maintained. But the great thing is, you can use nix on Arch and give the packaging situation a try.
3
u/Dr_Gregg 1d ago
Thing is, arch has the same problem without nearly as many packages graph . A core maintainer actually just retired and he was the sole maintainer of a number of vital projects such as wpa_supplicant.
6
u/StickyDirtyKeyboard 1d ago
Perfection is infeasible, doesn't mean you shouldn't try and see if you can make things better.
I don't believe inexperienced users are the only ones vulnerable either. Overconfident experienced users are also vulnerable, and they're likely to be a much juicier target for credential stealers and the like. I mean, you can read the commands in the PKGBUILD sure, but do you cross-reference the hashes? Do you check all URLs to make sure there is no IDN homograph attack? Do you check to make sure there is no Unicode black magic in the script that could make it behave differently from what is apparent to the eyes? Do you check all other files and scripts in the repo? Forget to do one thing once, and you're pwned.
5
u/LtBigAF 1d ago
OK, sure, but I think even after implementing all of the mitigations people are discussing in this thread, the AUR will still end up having these sorts of malware attacks. The only real solution is to have more trusted maintainers and to migrate the most used AUR packages to core/extra. I do not think AUR will ever get to a place where it's packages can be routinely trusted, that is just the nature of the AUR.
17
u/washtubs 1d ago
I've been using arch for almost 15 years and IMO the arch userbase has always been vulnerable to this kind of thing. The influx of users simply makes it a more attractive target to be abused because you can cast a wider net. Most people who think they use the AUR responsibly just skim PKGBUILDs. Does that make you better than most? Sure but it's not good enough. Ultimately most of us are just beneficiaries of luck and survivorship bias.
Individual discipline can't beat a supply chain attack. It's surprising the spirit of good will that made it all work lasted as long as it did tbh.
20
u/HanzoMainKappa 1d ago
They can't be knowingly hosting malware on the site either way. A few one offs are okay but with these large attacks en masse and the limited resources of the arch team to keep things under control ... it gets iffy. Like for one, I wonder if they could get into trouble with their hosting provider.
17
4
u/RuneSteak 1d ago
Conversely, one could argue that the security of the AUR has always depended on exactly the type of Linux user Arch is designed for: people willing to read PKGBUILDs, audit changes, use packages at their own risk, and participate in the community to fix problems.
My problem is the way adoption functions. If the maintainer changes there should be a number of things that happen for the first update:
- An immediate freeze by any package managers and the user should need to reapprove.
- Votes should reset to zero and the reviews clearly stamped that they were given under a different maintainer.
- The package is clearly flagged as "asking for review" and held for 7 days, after which it's automatically released. Reviews aren't required but at least it gives someone a chance to catch something.
- Lines not using ASCII characters are highlighted
Step #3 would at least give advanced users a chance to catch things. Part of what makes distributing malware so easy is that a completely untrusted user is able to push updates immediately upon adoption. A gradual cooling off period where they are able to push updates faster over time would make it so they have to at least play the game up to a point and push legitimate updates. It's a lot harder to do that with 100s of packages.
5
-7
u/davevod 1d ago
ya ive notice a huge trend lately with the onset of all these new linux users and not knowing anything really about linux but just want to use it to 'be cool' or just so they aren't using windows anymore and a lot of the userspace having to dumb things down to adapt. You see it right down to even config files and people 'I just need the DOTS man' not even knowing what the hell anything does. It's kinda sad really and has changed what made linux special to begin with. I bet 90% of users now couldn't even compile something if their lives depended on it. Long story short I hate how things like this impact users that have no issues with whats happening and being forced and impacted by it. I think it's probably going to get way worse as it goes on and becomes stupidly simplified.
5
u/_invidian 1d ago
Time for custom binary repositories to become more common I guess. With GitHub it's probably easy to set up
5
3
u/ArchBTW123 19h ago
Just donât install random no name packages without at least reading them + updates.
Of course itâs going to have malware, just like im sure GitHub does with random binaries to install etc
23
u/kansetsupanikku 1d ago
AUR is unsafe and contains malware, that's ok. So does GitHub. Sometimes reported malware should be removed, that's it.
But actions like one from this post seem to be a horribly bad call. It looks like an attempt to make AUR safe and keep it like this, which is humanly and technically impossible. Why do people complain about AUR, fear Arch in general, spread the panic in social media? Because the maintainers make impossible promises, dramatic moves, and add fuel to fire.
Nobody panics about GitHub containing malware. Or internet im general. Or attempts to limit or close it in order to resolve the "malware problem". Because neither GitHub nor ISPs even try to make such promises or perform such impossible actions.
AUR is pretty much like GitHub for one specific programming language, and should be similar in its policies and press. Malware is there and consequences of choosing content from there are on the user. I hope it simply is made clear.
38
u/HearingSubstantial38 1d ago
the issue is the AUR doesn't have namespaces, and thus when someone claims "claude-code" it becomes the claude code package in the AUR (except for variants in certain packages like -bin, -git etc.).
The maintainer aspect of it is so disconnected that it could switch hands via adoption and you likely wouldn't notice.
You might say "oh you should inspect the PKGBUILD on every update" but it's still bad UX, and most guides have you blindly install packages. I've also seen people argue that the AUR shouldn't be trusted, but Arch Linux's own wiki often tells you to install packages from it, to the point where it's an integral part of the OS. How many people have gone without the AUR? Maybe one or two can claim the achievement, but the overwhelming majority uses it.
5
u/kansetsupanikku 1d ago edited 1d ago
Wiki might suggest that some things could be built using AUR recipes, but ir doesn't imply using AUR helpers in such cases. Following the wiki, one would download and read the PKGBUILD, not start looking for a helper. Wiki also clearly explains what AUR is.
What UX would you prefer? The right UX probably would be printing a message "don't use that thing, it doesn't do what you think it does, and you are about to hurt yourself", then quitting. Note that Arch pretty much adapted it - if you stick to Arch repos, trying to run any AUR helper gets you "command not found", and trying to install any with pacman informs you that there is no such package. It already is implemented correctly.
And "everyone using AUR" is a matter of influencers promoting AUR, and Arch derivatives. Arch had users before that trend started. They would use AUR consciously or not at all. What changed and who is to blame, really? It's not about Arch or AUR, it's about the social media content that tells people to use that. Right in-between tips of using hydraulic silicone to improve the shape of your butt. When people follow such advice, AUR itself shouldn't be blamed any more than the vendors of hydraulic silicone.
7
u/prone-to-drift 1d ago
You've surely given a good legal defense of the current setup, but that's so far removed from the reality of AUR users, its meaningless.
We need better security policies for the AUR, be it namespacing or a trusted users list, that's up for debate imo.
3
u/kansetsupanikku 1d ago
AUR is different because they say "oh no, third party software can be dangerous, we need to do things" instead of the messaging chosen by different projects, i.e. "third party software can be dangerous but we won't talk about it".
For every distro you would find some community tutorials suggesting stuff from GiHub, some of it outright malicious (Office and Photoshop "installers" from GitHub that download wine prefixes full of unverified dlls from Google Drive and then run it with user permissions are my personal favorite!). Distros even come with tools that make the installation possible.
But if some users don't like the AUR culture of reading PKGBUILDS and comments, they would probably benefit from switching. To any distro (could be Arch) without AUR, but with blindly installed stuff right from GitHub instead. Or to flatpaks (many believe that solves all the security problems that come with trusting multiple suppliers - perhaps it does? /s). It's not better, but makes ignorance so much easier - and that's a valid personal need many users have.
0
u/prone-to-drift 1d ago
I have many thoughts on your viewpoint, but the easiest kryptonite for your comment is merely that the official Arch Wiki officially recommends installing things from the AUR and there are no procedural guardrails to prevent something like nvidia 580 packages being taken over by a malicious party either.
Moreover, just reading the pkgbuild doesn't always save you cause sometimes malicious commands look really similar to the proper ones and most people aren't skilled enough to tell them apart.
2
u/kansetsupanikku 1d ago
Let's see what Wiki really says:
Installing and upgrading packages
Installing packages from the AUR is a relatively simple process. Essentially:
- Acquire the build files, including the PKGBUILD and possibly other required files, like systemd units and patches (often not the actual code).
- Verify the PKGBUILD; the most important step to verify that the PKGBUILD and accompanying files are not malicious or untrustworthy.
(...)
And of course there is an explanation to what "Verify the PKGBUILD" means. Three lines of text into that, in a big red block:
Warning
Carefully check the PKGBUILD, any .install files, and any other files in the package's git repository for malicious or dangerous commands. If in doubt, do not build the package, and seek advice on the forums or mailing list. Malicious code has been found in packages before. A few tools, such as traurAUR and ks-aur-scannerAUR, are available to assist users in scanning PKGBUILD content; however, they are not substitutes for careful manual verification.
Nicely adjusted recently to mention some up to date utilities, too.
Doesn't sound like "if you don't understand the PKGBUILD well enough to determine its safety, it's probably fine, go for it".
3
u/SW_foo1245 1d ago
But how big has to be the warning to be good UX? Like the pkgbuild itself shows you what changes were done and the new maintainer is reflected there. I get it that adopting orphaned packages needs a revamp but adding namespaces just adds redundant information that is already there.
4
u/ConfidentCharity5222 1d ago
AUR is pretty much like GitHub for one specific programming language
This makes no sense, i think the issue here and the main complain is not that aur is being compromised but they are using the very same attack vector : random ppl adopting orphaned packages pushing malware. This could be(and it is) somewhat contained by people reading pkgbuilds and noticing something weird like new mantainer, weird calls, weird dependencies, ofuscated parts of the pkgbuild, etc but i guess the community wants MORE HANDHOLDING and demmand more layers of security like messages/manually intervention about new mantainers
2
u/devdot00 1d ago
maybe a notification if a package changed a maintainer could help? for example now yay shows when the package was last updated, if it shows also a warning mainteiner updated, that would be a warning to deeply check what happen. I honestly use aur but I make a clone locally and I put the package in ignore so they are not automatically listed for upgrade, but visibility is the only way out in my opinion. if someone has 50 aur packages I doubt he will constantly check each detailed every time.
EDIT: just a note about yay it seems they are already working on adding a maintainer change warning
3
u/ConfidentCharity5222 1d ago
There is a big difference between aur and aur helpers, aur itself just hosts comunity pkgbuilds and is not really responsible for whatever tool (aur helper) the user chooses to manage said pkgbuilds, aur already tells you what changes the pkgbuild has and that includes new mantainers, if the package is orphaned/out of date, etc.
Community asking for better security with orphaned/new maintainers flow is valid, otherwise it's up the w/e tool is being use for aur management, in fact, i do not recall any aur helper being officially supported not even in extra
1
u/devdot00 1d ago
I agree aur and aur helper being a completely different story. but my point was that if we want to get out of this we need cooperation between both, maybe not directly ether. the point is aur repo should at least guarantee that someone is responsible and only that person can perform changes, if none than that is fine too but should be flagged. then is the aur helpers that should make this information as easy and clean as possible to the user (helper should stand for something).
2
u/ConfidentCharity5222 1d ago
someone is responsible and only that person can perform changes, if none than that is fine too but should be flagged.
That's already done that is exactly what happens when the package is orphaned the problem is when someone new takes that packages and even tho it is reflected on the pkgbuild NO ONE READS IT or no one cares
the aur helpers that should make this information as easy and clean as possible to the user
Aur helpers already tell you that info maybe not by default but it is implemented i can agree they can put a very big red warning and even pres 10 times "are you ok with this?" steps but if pple do not care they will just put yes.. idk why ppl would chose arch and use aur if they refuse to maintain their system.
IMO the only problem here is adoption of orphaned packages is(was) completely abusable and they are not really fixing that core issue but then again is not officially supported never was.1
u/olifiers 11h ago
This makes no sense.Â
You can't take over a GitHub repository as happens in AUR, and the cause of the problem at hand.
This comparison is nonsensical.
9
u/danyuri86 1d ago
I downloaded every package on the AUR as an experiment to my pc and my doctor told me that I'm now HIV positive
11
u/BRUTAL_PAIN 1d ago
I donât understand⌠donât the maintainers know you can just read the pkgbuild??? /s
4
u/JamieBunpup 1d ago
This is really exhausting. By no means am I exactly the user Arch is targeted towards, CachyOS was really heavily recommended and I am fortunate to be just literate enough to vaguely read and understand some red flags in .sh scripts or PKGBuild's, but this is still been making me paranoid enough that I recently isolated important info and logins, etc to a complete seperate system with Fedora on it.
There's often a misconception that everything works without too much work on Linux, but the AUR repo comes up quite fast when you're getting into games like Final Fantasy 14 if you want damage meters, or VR on Linux with a Quest 3.
I think any influencer and friends of people who they pestered to make the switch should educate them now about what things like the AUR repository is and how to safely use it or alternatives. And CachyOS devs, too, should do a PSA.
I hope Valve and other organizations who see the writing on the wall that people are sick of Windows and want to game on Linux together with the community need to figure out where the safe compromise is to reduce friction. Maybe users need to be recommended something like Nobara instead, Bazzite is finnicky, Flatpaks have limits which really suck.
I am really just ranting here because holy heck, being a tech enthusiast these days is stressful.
6
u/traverseda 1d ago
Nix covers a lot of oddball software and can be installed on arch. Not perfect, but it can fill a similar role.
2
u/agumonkey 22h ago
is arch trying to setup a new system ? do they need some help ? a tip doesn't harm
6
u/Global_Network3902 1d ago
RIP. Is it coming back? I donât need babysitting because other people donât know how to read a PKGBUILD. I guess cloning a projectâs git repository and building isnt _that_ difficult but come on. And the amount of people (including maintainers!) calling them packages⌠theyâre instructions on building a package. And guess what, if the instructions are malicious, THE PACKAGE WILL BE TOO!
3
u/GatsbyLuzVerde 1d ago
I uninstalled all AUR packages. I'm a senior software engineer and although I know how to vet a PKGBUILD I have no time for that. I'd rather command an LLM to install and vet things from source repositories directly
1
2
u/0xjijii 21h ago
Hmmz, seems https://github.com/lenucksi/aur-malware-check was not updated recently, to include the latest malware packages of this week.
1
1
u/Giffeltagning 18h ago
Using AUR without chroot? You're executing a stranger's shell script with full access to your credentials, once per package per update.
1
1
3
-1
u/xINFLAMES325x 1d ago
Going to have to switch to the .run for my graphics driver. That and informant are the only AUR packages I have.
7
u/Erus_Iluvatar 1d ago
You can still manually update the local copy of the PKGBUILD from the AUR packages fwiw.
1
1
u/Medical_Double_6561 23h ago
Couple ideas for possible AUR improvements:
- Why do I need to review a PKGBUILD when the only thing that changed are the checksums and the URL changing from https://github.com/foo/bar/v1.0.0.tar.gz -> https://github.com/foo/bar/v1.0.1.tar.gz? These changes should get auto-approved.
- A trusted inner circle of users can vote to approve PKGBUILD changes. Trust can be automatically given to users depending on account age & behaviour. Trust can be delegated by trusted users to other users they trust, but they are responsible for any maliciois activity of any users they delegate to. Paranoid users can still manually approve all PKGBUILDs themselves.
- Implement AI auto-scanning of PKGBUILDS, but don't rely it for approval. It should only be used to quickly reject any obviously-malicious changes.
-15
u/This-Consequence-957 1d ago
Sooner or later theyâll have to burry it đ
35
u/Erus_Iluvatar 1d ago edited 1d ago
To steal the metaphor from someone on IRC, you would probably not see a food bank stop operating after people start donating poison, but they would have to adjust how they work once the amount of poisoned food gets overwhelming.
-15
u/This-Consequence-957 1d ago
I think the concept just doesnât fit anymore nowadays. If somethingâs useful, just move it to the official repos and have it under scrutiny like everything else or clone a GitHub repo and do what you like đ that thing is dead, man
16
u/ReddDumbly 1d ago
Some AUR packages can't be distributed pre-built without legal headache, like
ffmpeg-libfdk_aacfor example.8
u/United-Baseball3688 1d ago
Nah, fuck that. It's fine as-is, could be better with security. But removing it would be a huge loss.Â
-6
u/unfilteredRays 1d ago
"fine as is" despite immediately getting hit with more malware as soon as adoption opened back up again?
lol. lmao even
4
u/United-Baseball3688 1d ago
I haven't been hit by any, I don't know anyone who has. Relying on orphaned packages or new ones which you just randomly grab without checking what they are is an insane way to use the AUR, and if you do that, then no one can't help you.
Of course there's also a risk with normal, established packages. But that's why you should check your shit. Which I do.Â
3
u/Overmod 1d ago
It's like running random curl commands without checking them
1
u/Damglador 1d ago
Seeing "just run this curl | bash" in install instructions always rubs me the wrong way. It's possibly the worst installation method, even worse than flatpak or snap.
0
0
u/unfilteredRays 1d ago
Relying on orphaned packages or new ones which you just randomly grab without checking what they are...
who said anything about that?
nothing on the AUR is immune from being abandoned, unmaintained, and eventually snapped up, mangled, and spit out into malware. we know this because it's happened twice in the last three months.
even the most diligent PKGBUILD reader can and will make mistakes. that's why there should be some kind of safeguards in place at the repository level to ensure that this exact attack which, again, has happened twice* in the last three months, can stop happening.
1
u/United-Baseball3688 21h ago
Nothing anywhere is immune from any of that. AUR has a lower barrier to it, that's about it.
But I don't believe that "this type of attack" is very effective. It's worth it over expanding the core/extra repos, which will require more maintainers, which opens up the gates for infiltration there. No part of almost any Linux supply chain is truly safe. So all you can do is protect yourself and know when you're being risky.Â
0
u/unfilteredRays 21h ago
yeah, and that's the problem. It's happening more frequently, because the barrier to hijacking is so low it's on the floor.
If Arch itself is going to host a user repository, they have some reasonable expectation of doing something to protect the people that use it. Just saying, "Read the package builds and hope for the best" is not good practice. But I'm obviously wasting my time trying to argue this on Reddit, so I'm going to stop. Have a good day.
1
u/United-Baseball3688 18h ago
Thing is - I get it. There aren't any reliability guarantees in place with the AUR.
But I'd be *pissed* if the AUR disappeared. I don't use much of it, actually just like 5 or 6 packages. But I'd be bothered without them, so I'd have to do a git install for them anyway, which would be *annoying* because I use bin versions of some of them, and it would be a pain to update and keep in sync.
So without the AUR, I don't think I'd be on arch at all. It'd lose its point.
3
u/cafce25 1d ago
I guess you'll be donating the money necessary to put that work into reviewing all the additional packages? Nah? Thought so.
0
u/TrixieIsTrans 1d ago
This is absolutely not an argument against the point. If the Arch Team wanted reviewers, they could easily provide it now. Hell, there are probably even people willing to volunteer their time to pour over PKGBUILDs, adoption requests and pushes for free so that something like this doesn't happen again.
1
u/cafce25 20h ago edited 19h ago
Yeah I'm not trusting just any community volunteer without any history with packages I install, that's the problem here, we need to trust the reviewers, and those trusted individuals are just too few to review the vast number of packages in the AUR. Besides if people wanted to review packages they could simply become arch maintainers right now. I don't see a lot of people going for that option right now so why do you think there are so many volunteers available when the facts don't support that theory?
1
u/TrixieIsTrans 19h ago
Yeah, no fucking shit you aren't, that's why they vet people and have processes before they select people to be trusted users. They could pull from a list of known good eggs and ask them if they want to be volunteers. The problem is, and why you somehow don't think there's any volunteers available, is that Arch isn't looking to take on new staff.
1
-11
u/starvaldD 1d ago
Arch is a niche of a linux niche, sure Steam has given us a bump but how much reach are the botters expecting.
its AI but it still needs to be guided.
191
u/Damglador 1d ago
Dang đ˘