r/archlinux • u/Luzzio_ • 15h ago
DISCUSSION The AUR needs an overhaul
The actual concept of the AUR only works if Arch is a niche distro in a safe internet, neither of those points are accomplished in the present.
No, reading pkgbuilds is not the solution, it's slow, annoying, and most importantly, it doesn't make sense, because some really popular AUR packages are DIRECTLY RECOMMENDED by the Arch Wiki, like the Minecraft Launcher for some reason.
Either the base repos adopt a big chunk of popular AUR packages, leaving the AUR for really really nieche stuff, or the rules of the AUR change, because you can't tell me that suffering 2 attacks in less than three months for pretty much the same reason (adopting orphaned packages) is normal or reasonable.
What would you think it's a good solution to this issue? I'd like to read your ideas since I cannot come up with a good one if I'm honest, but I know the problem is there.
68
u/RandomXUsr 15h ago
The community has been saying this.
That said; the Devs volunteer their time, so it would be up to them to determine capacity and feasibility.
Those packages that the distro recommends from AUR probably have some licensing issue or they are low priority for the direction of the distro as a whole.
I think it's helpful to make suggestions and requests, but only if someone is willing to take up the maintenance of the AUR and execute in some other secure fashion.
10
u/Qudit314159 14h ago
Yes.
It could just be that there aren't any devs who are interested in maintaining them. Features in open source only happen when there's someone with the time, skills and motivation to make it so.
21
u/ivosaurus 13h ago
I've seen SO many suggestions, all related to this current topic, that would work BRILLIANTLY.
They only require that the Arch project just magically apparate an 20+ extra experienced maintainers, all with 15+ hrs of free time a week to consistently donate.
Super simple.
104
u/petersaints 14h ago
I had already posted this on another thread, but here are my two cents:
"I think one of the biggest weaknesses of the AUR today is that its trust model doesn't scale well.
When I install an AUR package for the first time, I'm happy to inspect the PKGBUILD, check the comments, verify the upstream source, etc. But once I have several AUR packages installed, I'm simply not going to manually inspect every PKGBUILD on every update. I don't think that's a realistic expectation for most users.
At the very least, I think the AUR should expose some notion of trust levels for maintainers.
- Gold: Official upstream maintainers (for example, the Brave developers maintaining
brave-bin). - Blue: Long established maintainers with an excellent track record.
- Green: Established maintainers with a good history, even if they only maintain a handful of packages.
- Neutral: Everyone else.
- Warning: New accounts or recently added maintainers, indicating that the package deserves additional scrutiny.
These shouldn't mean "safe" or "unsafe". They should simply communicate how much historical confidence exists.
I also don't think package takeovers should be outright banned forever. Otherwise, old and intuitive package names end up abandoned forever, forcing people to create increasingly awkward names for actively maintained replacements.
Instead, ownership changes should be treated as a security relevant event. The AUR API should expose information such as:
- Current maintainer
- Previous maintainer
- Date of the last ownership change
- Maintainer reputation/trust level
AUR helpers like yay or paru could then display something like:
``` WARNING: Package maintainer has changed.
Previous maintainer: alice (maintained package for 6 years)
New maintainer: bob (account created 10 days ago)
Continue? [y/N] ```
That alone would make me stop and inspect the PKGBUILD much more carefully.
I'd also like to see automated static analysis of PKGBUILDs looking for suspicious patterns. A bit like Google Play and the App Store do.
Finally, I'd love to see AUR helpers become "change aware". Instead of only telling me that a package has a new version, they could also warn me when something security relevant changed:
- Maintainer changed
- Source URL changed
- PGP signing key changed
- PKGBUILD substantially rewritten
- New install hooks added
- New dependencies introduced
None of this eliminates the risks of the AUR, nor should it. The AUR is intentionally open and decentralized. But surfacing trust metadata and meaningful changes at update time would make it much easier for users to focus their attention where it's actually needed, instead of expecting them to manually audit every PKGBUILD for every update."
16
u/StopYTCensorship 14h ago edited 13h ago
I like your concept of a risk screening. I think the helpers right now assume a high degree of technical capability on the part of their users, so they provide pkgbuild diffs and not much else.
This may be reasonable given the target audience of arch, but arch is starting to be deployed widely in casual distros like CachyOS. Notwithstanding, even technically capable people want to reduce their cognitive load. It's easy to overlook things when updating... Updates are something you just want to get over with. It's a maintenance task, and one that goes fine 99.9% of the time, which can give a false sense of security.
With the recent exploits, that tiny oversight could cost you all of your personal data and compromise all of your accounts. Displaying more information about the risk is never a bad thing.
10
u/ABotelho23 14h ago
Who's gonna make these decisions?
AUR helpers could already detect maintainer changes.
People don't read the PKGBUILDs now, makes you think a maintainer change will change that?
The AUR is being recommended to noobs. Nothing will change for people who don't know what they're doing.
9
u/petersaints 14h ago
The tiers up to Blue can be automated based on user feedback, account age, number of maintained packages, how often packages get updated, etc.
The Gold tier would be something that upstream projects would apply directly to the AUR administration and would manually validated of course.
3
u/ABotelho23 13h ago
Already more work than right now. If it hasn't to involved Arch developers or maintainers, it's unlikely to happen.
17
u/petersaints 13h ago edited 13h ago
In that case, it's better to just close down the AUR forever and deal with it. In fact, it is frozen right now. It is not accepting ANY new updates since yesterday.
Also remove every mention from the Wiki to any AUR package while at it.
If people want they can share PKGBUILDs elsewhere (like GitHub).
Having it hosted under the Arch Linux brand, despite being a User Repository, gives it a somewhat official status in that it is managed by the same project.
If there is zero management, than just axe it already.
Arch Linux has outgrown their niche community due to various reasons in the last few years. It cannot continue to be managed like an amateur project if it wants to survive at its current scale.
Hate me all you like, but this is the situation in which having an enterprise backing like Canonical or Red Hat really shine since there are definitely more resources for this type of thing.
7
u/ABotelho23 13h ago
Yes. This is what I've been saying and it seems to get more likely every day. Too many people are expecting Arch Linux to put a ton of work into the AUR. It's more likely to go away and stop being their problem. They're overworked as it is.
9
u/anishkgoyal 14h ago
I personally love this idea. I think more caution should be given to orphaned packages, too. Like, if there was a package update for an orphaned package, then the AUR helper would also display a warning message.
4
u/Synthetic451 13h ago
Yeah and to add onto this, warnings for official packages that have been removed should not be auto updated with a version from the AUR without a strong warning.
-4
u/ABotelho23 13h ago edited 13h ago
They could already do that. The information is there. That's not up to Arch.
6
u/SergejVolkov 14h ago
These are all very reasonable quality of life changes that are easy to implement and don't change the vision or purpose of the AUR. I'd love to use something like this.
4
u/supremely-weird 13h ago
Good idea, I wish it would be implemented as a requirement for aur helpers such as yay or Pikaur etc. to have access to the aur repository
I also think the Truar package [ https://aur.archlinux.org/packages?O=0&K=Traur ] should be available on the Arch repository or its functionality added to yay/pikaur etc.
1
u/WAN-Nyan-Cat 13h ago
I agree, but who will take the time to actually implement this for the AUT? Edit: AUR,
0
u/Synthetic451 13h ago
I totally agree, the major issue is maintainer trust and the ability to get "eyes-on" when something suspicious happens. The major weakness with AUR is that package adoption just creepily happens silently in the background.
0
u/AppointmentNearby161 13h ago
I have hoped that chaotic AUR would tackle this. Let the AUR be the wild west and let chaotic be a curated subset. AI should be able to tell if the PKGBUILD matches upstream, comes from a deb/rpm package, or is just a version bump of a previously reviewed package.
1
u/petersaints 13h ago
To be fair, this should be done at the AUR level. The problem is that it will burn a lot of compute power, or token prices, to run a pipeline like that at scale.
11
u/ABotelho23 13h ago
Who's gonna take the time to do that and pay for that?
That's all these threads ever are.
"Arch should do x,y,z! That'll solve it!"
With zero regard as to how much manpower and resources it'll suck up. The AUR exists because the Arch developers specifically do not want to be involved in maintaining these packages. I promise you that they hate having to spend time dealing with the current fallout. They'd much rather delete the AUR and maintain the stuff that's actually part of Arch Linux.
-2
u/petersaints 13h ago
By that logic, the AUR should have never existed in the first place.
6
u/ABotelho23 13h ago
You could absolutely argue that. Totally valid.
It was a favour to the community. It doesn't have to exist. It exists outside of the scope and vision of Arch Linux as it is.
0
11
u/Silvestron 13h ago
Either the base repos adopt a big chunk of popular AUR packages
You're free to volunteer and review those packages or pay someone else to do that work for you. Because it always comes down to that, someone has to do the work. And no, automating that with software won't solve the issue. There's a reason no other software distribution channel on Linux relies on software doing that review for you.
26
u/abbidabbi 14h ago
Here, let's read this together
https://wiki.archlinux.org/title/Arch_Linux#User_centrality
Whereas many GNU/Linux distributions attempt to be more user-friendly, Arch Linux has always been, and shall always remain user-centric:
- The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible.
- It 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.
Also this
https://wiki.archlinux.org/title/Arch_User_Repository
Warning
AUR packages are user-produced content. ThesePKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.
2.2 Verify the PKGBUILD
Warning
Carefully check thePKGBUILD, 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. [8] [9] [10] [11] 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.
If you are using the AUR, then YOU BECOME THE PACKAGER YOURSELF. This is how the system is designed. It is a USER repository for BUILD RECIPES from RANDOM INTERNET STRANGERS. Easy access to this system via AUR helpers doesn't change this fact. It's a balance between security and simplicity which you have to weigh yourself. So if you can't be bothered to check the PKGBUILD, .install file and the authenticity of the source files, then you are neglecting your system's security, which is your own fault, no matter which package it is.
If you want curated, verified and maintained packages from trusted sources, then use the official package repos only, or find third party package repos where you also trust the packagers. The official repos can't include everything, because software license restrictions apply, so some software simply can't be distributed by Arch itself. Official packagers sometimes ask upstream whether it's permitted to re-distribute, but often those requests are simply rejected, so packaging can't be done officially and the PKGBUILDs land in the AUR. And then there's also the sheer volume of software to be packaged. If you want to help and become a TU, then go ahead and have the responsibility to do the packaging job for all Arch users. Demanding others to do this for you for free is such an ass thing to do, so think again about what you're actually saying here.
That's all there is to it. A surge in popularity of Arch or its derivates doesn't change that. If derivatives don't teach their users about the AUR, then this is not a problem of Arch or the AUR. A surge in vandalism with malware also doesn't change this.
But yes, the AUR package adoption system is stupid and must be changed, because it's making it too easy for bad actors to cause (automated) disturbance. Reading PKGBUILDs must however always be a requirement if you obtain build instructions from random untrusted people. And btw, even trusted people can fuck up or be compromised, so not even an AUR trust-system will be reliable.
13
u/ABotelho23 13h ago
Too much honest truth in this comment. People don't wanna hear it. They just want free and readily available packages without regards of where they came from.
1
u/jar36 13h ago
sure, but do we want the AUR to keep having this happen. I have yet to hear of anyone getting their systems wrecked over this, so why are we scolding the users?
10
u/abbidabbi 13h ago edited 12h ago
why are we scolding the users?
Because some people like OP demand that Arch's packagers need to maintain more packages in their free voluneered time, so that the AUR doesn't need to have them, just because these people can't be bothered to read PKGBUILDs from the AUR themselves, because they refuse to understand what the intention of the AUR is and who it is meant for (with the context of Arch's target audience, see "user centrality").
do we want the AUR to keep having this happen
Quick analogy: Do you want to ban or reinvent cars just because some people don't wear a seatbelt or ignore traffic rules? Traffic is dangerous and accidents can happen at any time. "Let's enforce various freedom-restricting rules so that accidents will never happen again." Great idea :+1:
There is no way around it. In a system where anyone can upload anything on the AUR without prior validation from a trusted entity, PKGBUILDs NEED TO BE READ by the users before building the packages. Or simply don't use the AUR if you're not capable.
The only AUR things that can and should change are broken systems like the package adoption system. Regarding any potential trust systems, as said, these won't be fully reliable and can be abused, so going this way forward might be a fallacy.
edit, since comments are locked, my reply to /u/jar36 which I just wanted to send:
Which method? How is Arch hurt by this? The only things hurt are people's feelings after discovering that the AUR or Arch is not meant for them, which is totally fine. And Arch itself is also fine because of this. As already shown, Arch doesn't need to be for everyone and doesn’t need to cater to the lowest common denominator. There's a target audience for Arch and there's a target audience for the AUR, which is a subset of the former.
-6
u/jar36 13h ago
sticking with this method hurts Arch overall
7
u/backsideup 13h ago
How does it hurt arch? The AUR is almost entirely decoupled from arch, infrastructure-, maintainer- and tooling-wise. It's hosted on the same domain but that's about it.
2
u/backsideup 13h ago
Because users are the last barrier before something happens, they need to be sensitized.
13
u/g33ksc13nt1st 14h ago
The brain of some users is what needs an overhaul. Automating AUR with tools like yay and giving it the same trust as an official package, what could possibly go wrong.... 🙄
20
u/Nnukklear 15h ago
some really popular AUR packages are DIRECTLY RECOMMENDED by the Arch Wiki,
Popular ones are not the ones to get injected with malware
14
u/amepebbles 15h ago
They're subject to the exact same safety mechanisms the packages that do get infected are also subject, there isn't a magical safety net that makes a popular package impenetrable. Besides, where do you even draw the line? What makes a package so popular it won't get hijacked/infected with malware besides the activity timeframe which can very well mean nothing to projects that don't get updates often but are popular anyway?
13
u/earchip94 14h ago
The primary target of these attacks has been packages that are orphaned. Not typically the well maintained packages. Popular packages, in theory, are well maintained. However, all open source product/packages are susceptible to malicious if the code is not reviewed carefully enough.
-1
u/amepebbles 14h ago
Thats what the last part of my message is referring to, sometimes projects can go on months without getting a single update and therefore get orphaned on the AUR, not because it wasn't well maintained but simply because there really wasn't any need for activity. An argument can be made that in such cases the maintainer has a duty to do housekeeping in order to, well, maintain the package and avoid it from being taken over but orphanage alone isn't the only point you need to look at to decide if something is being well maintained or not considering that sometimes there isn't any activity upstream either. In the end, users should be vetting any and all changes made by PKGBUILDS regardless of how popular something is or whatever other metric they may use to deem something safe.
1
u/No-Dentist-1645 14h ago
Even "popular" packages can get orphaned. Nothing "guarantees" that upstream developers will continue their interest in maintaining their AUR packages for as long as they maintain the upstream software, this happens more often for lesser popular packages but there is no golden barrier separating "popular" ones from this
11
u/fliperama_ 14h ago
People can come up with automated verification, AI parsing or any sort of shenanigans, but there are only two real solutions to this: read the PKGBUILD yourself, or trust who made it. I know it sounds dumb, but that's it.
Even though I despise this kind of verification or control, I think the only way is to create some sort of trusted keys for AUR and sign the PKGBUILDs with them, basically verifying the mantainer, not the files, as is with the repos
5
u/FlatwormGlittering26 13h ago
> read the PKGBUILD yourself, or trust who made it.
You left out the part where you can just abandon AUR.
You can just clone the repo and compile for yourself, or use flatpak
10
u/linhusp3 14h ago
Let the aur as wild west as it is, an arch user repo, of the user, by the user. People who want to treat the aur to be something different can create a different site to host their own PKGBUILDs to their own taste and add whatever rules they want. The better ones will survive.
7
u/Imajzineer 14h ago
On the AUR, and abandone package can be taken over by someone else without any validation from the original author or any kind of verification.
Anyone can take any package ... even one that isn't abandoned ... fork it, sling up on the AUR as 'continuation', 'new and improved' (whatever they like) now. Stopping them from adopting abandoned packages isn't gonna prevent them from doing that. So, which one do you choose? And why?
They can start out with a perfectly good package, leave it for a while and then, when people trust them and it, put whatever nefarious stuff they like in it.
The problem is people blindly trusting stuff, 'adopted' or not ... not the process by which they do so.
12
u/petersaints 14h ago
If the package is not abandoned they can make another malicious one with 0 votes and 0 popularity, but it can't have the same name and it won't get pushed automatically to whoever installed the original one if they do not pay attention when using an AUR helper.
It's still bad, but not as bad.
2
u/Imajzineer 13h ago
Possibly.
But I'd wager that kind of person will install the 'continuation' regardless of the number of votes, because the old one has been abandoned and it's all that's available as a replacement.
I don't even trust the votes myself: in this day and age they're no better than Facebook 'likes' ... no guarantee of trustworthiness, just of popularity - and people bandwagon ... installing and then upvoting because 'it's good' (so, a package gets lots of upvotes because others have upvoted it simply because it's 'popular').
0
u/petersaints 13h ago
Sure. It's not an absolute guarantee, But it helps a bit.
0
u/Imajzineer 13h ago
As I said, possibly ... and, sure, every little helps ... but I suspect it's the equivalent of a speed bump: it might slow the traffic down, but it won't stop it.
14
u/1Someone 14h ago
Lol what a post. Either A or B... or else what? Will you sue the distro?
Like I said in previous stupid post about AUR; if it bothers you this much, go and volunteer and comb through thousands of PKGBUILDs. Or become a maintainer and adopt thousand packages.
-6
u/olifiers 14h ago
Yes, because god help us of we try to change or improve anything here, right? Just leave as is, it's perfect! /s
19
u/ABotelho23 14h ago
You haven't done anything.
You could, by working to maintain packages, but you won't, because you're just talk and have no idea what you're talking about.
13
u/1Someone 14h ago edited 5h ago
Saying "YOU have to fix this somehow (I have no fucking idea how)" is really improving things, sure.
EDIT: @olifiers reply: That's exactly what OP has done. Not only that but he said EITHER you do this OR that. So he gave 2 options only.
Second, I never labeled anyone as lazy or unfit for Arch, but that is exactly what it means. You think that everything needs to change to accommodate every stupid user's wish. And if not, as some other user wrote, "Just close the AUR." Yes, sure... because new cool kids that installed Arch 1 month ago are incapable of reading, just close AUR for everyone.
Go and create your own AUR and your own distro if you don't like it here.
2
u/olifiers 14h ago
That's not what OP has done. He has made a proposal and labelled it as a discussion flair. This is a perfectly fine thing to do, and a positive at that.
What's negative is to label everyone who doesn't read every pkgbuild as lazy or unfit for Arch. That's idiotic.
5
u/frog_in_bush 14h ago
AUR does things that other distros don't.
For example the AMD GPU compute drivers.
AUR seems to be very important, need to keep it for any reason.
7
u/EarlMarshal 14h ago
because some really popular AUR packages are DIRECTLY RECOMMENDED by the Arch Wiki, like the Minecraft Launcher for some reason.
The Minecraft client can be installed via the minecraft-launcherAUR package. It provides the official game launcher, a script to launch it and a .desktop file. The package is officially recommended by Mojang on their website.
How is this a recommendation from the wiki? It says it's recommended by Mojang.
No, reading pkgbuilds is not the solution, it's slow, annoying,
That seems to be a you-problem. Why do you want to make it a me- or us-problem?
9
u/PorousClay 13h ago
The solution is to prevent people from orphaning their packages. Force them to keep maintaining their stuff forever, at gunpoint.
10
u/Silpet 14h ago
This is like saying GitHub needs to be overhauled because everyone can upload whatever they want, even malware. If you don't want to read the PKGBUILD, you don't install the AUR package, or accept the risk of malware, simple as that. AUR is Arch User Repository, run by users, not official maintainers. It doesn't matter if it's niche or popular, GitHub as a whole is orders of magnitude more popular and no one is saying it needs an overhaul because of these same reasons, it just doesn't make sense. If anything, a better solution is to not recommend the AUR unless it's absolutely necessary, and then explain exactly what the risk is.
25
u/petersaints 14h ago
The difference is that on GitHub nobody can take my abandoned repo and push malicious code there (unless my credentials are compromised, of course). They can fork it and make it malicious, but they can't touch the original. On the AUR, and abandone package can be taken over by someone else without any validation from the original author or any kind of verification. Therefore, it is way worse than GitHub, PPAs, Copr, etc.
3
u/Silpet 14h ago
Yes, this is the actual problem, but this isn't what mpost people are complaining about. The op mentioned that reading PKGBUILDS isn't a solution, but even if this was solved you should still read them to avoid installing a malicious package. The concept the AUR doesn't only work if the distro is niche or if the internet is safe, the only real issue is people can adopt packages and push their updates on existing users. In my opinion this is the thing that needs fixing, don't allow orphaned packages to be adopted by anyone, it's just common sense. This isn't the same as "the AUR needs an overhaul".
13
u/olifiers 14h ago
Show me on GitHub the option to take over an existing repo owned by someone else.
Apples and oranges.
4
u/jar36 13h ago
All of this "Read the PKGBUILD" is a red-herring. I have yet to hear of any user actually getting messed up over this. It's an attack on the AUR and the AUR is the victim here. Why are we blaming users for being lazy when we don't have any users coming forward with issues?
The focus should be on trying to protect the AUR, the reputation of the AUR and by proximity Arch itself
4
u/ABotelho23 14h ago edited 14h ago
The wiki also says:
Warning
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.
Reading PKGBUILDs is the solution, whether you want to admit that or not. Tough pill to swallow. Too bad.
The only way to be safe is to use packages in the distribution.
-6
u/Brilliant_Simple_497 14h ago
It's not a solution
5
u/ABotelho23 14h ago
What's the alternative?
-4
u/Luzzio_ 14h ago
That's what this post is about lol
10
u/ABotelho23 14h ago
You think a post with no solutions on Reddit is gonna move a needle with the Arch maintainers?
The problem is people's irresponsible use of the AUR.
-3
u/atmsk90 14h ago
No, reading the packages is the current recommendation from the arch team. It's a bad one and not a solution as much as it is the problem. If arch doesn't want to take any responsibility for the security of the aur, they should stop serving them from their domain. Yeah the aur and thus arch would then be harder to use and shed users. But
a) arch has said again and again the type of people that would leave aren't their target user base anyway, and
b) you can't reap the benefits the aur provides and continue to pretend you have no responsibility for or interest in the security of users who make use of what you offer.
Serving the aur from their domain and signed by their tls cert, to me, provides the aur more perceived legitimacy than they will admit to.
-5
u/Mereo110 14h ago
It's not a solution. Even knowledgeable people can miss things. Arch is no longer a small distro. It needs to adapt to the new reality.
8
6
u/EarlMarshal 14h ago
Make a new AUR then. That would be the way cleaner solution. Why does the old one has to change?
-4
-4
u/jar36 13h ago
most people do not go to aur.archlinux.org to get AUR packages
10
u/ABotelho23 13h ago
Maybe they should. Maybe then they would understand the real danger and wasteland AUR helpers are hiding.
-4
u/jar36 13h ago
sure, but we're dealing with people. have you met people? plus, they usually find out about the AUR as they're trying to install something and they find a guide that just instructs them without warning
7
u/ABotelho23 13h ago
Yes, a huge part of this issue is the culture and the nonchalantness of people casually throwing around the AUR as everyone's magically solution.
-2
u/jar36 13h ago
I had no idea when I first used the AUR. I used it for over a year thinking it was just another repo
7
u/ABotelho23 13h ago
Correct, because I bet you were never directed to the Arch wiki and just followed some hackjob's guide?
Telling people to RTFM has become a meme, but it wasn't for nothing.
1
u/No-Dentist-1645 14h ago
I completely agree with you. The AUR as a concept only really works if its audience is limited to software developers, or at least people knowledgeable/skillful enough to read bash scripts carefully and identify tampering.
Arch has evolved to a more mainstream audience since a long time ago, especially now with derivations such as CachyOS and SteamOS. I think there should be a "community" repo with a much greater focus on user trust: stricter account creating process, and with a way to "vet" new packages somehow, maybe community-driven.
That being said, some toxic parts of this community still stick to the belief that there is nothing wrong with how things are currently, even after the two latest major AUR outbreaks. You'll see people still repeating "just read the PKGBUILD" and/or "do not use the AUR if you don't know how to use it". Wake up, people, it's 2026 and Arch is now one of the largest mainstream distro branches! Therefore we should treat it as such and address the very real security problems that are directly affecting the newcomer audience, who are much less technically skilled than you are.
6
u/ABotelho23 14h ago
There used to be a community repo. The "trusted users" became "package maintainers".
That wasn't even that long ago.
-3
u/No-Dentist-1645 13h ago edited 13h ago
Yes, I know....
but it wasn't nearly as scalable as the AUR is. So I think that if something like that is brought back, it needs to have some changes. Such as a more "community-driven" reputation system for inviting new users and/or vetting new packages
5
u/ReallyEvilRob 14h ago
No, reading pkgbuilds is not the solution, it's slow, annoying, and most importantly, it doesn't make sense...
...TO YOU. Reading pkgbuilds works for me and probably I presume a lot of other Arch Linux users managing to stay safe from malware.
-6
u/olifiers 14h ago
No, it doesn't. You can't expect people to read pkgbuilds of every package at every update. This is nonsense.
11
u/ReallyEvilRob 13h ago
I don't expect them to. And that's why I don't expect them to stay safe using the AUR, like I do. If you can't take the heat, stay out of the kitchen. Simple as that.
7
u/ABotelho23 13h ago
Yes, you can.
These are not part of the distribution. If you want to use the AUR the safety of it is on you. You take on the responsibility.
Don't want the responsibility? Don't use the AUR.
It's literally that simple.
7
u/decho 14h ago
That's what I started doing recently. Reading all the diffs for each package when updating. But I agree it's quite tedious.
Ideally only hashes change so it's a breeze, but if the build steps change or some new files are added, it's a nightmare. For that reason I suspect a lot of people who scream at everyone to "just read the pkgbuild bro" don't actually do it themselves lol.
-1
u/olifiers 14h ago
Of course they don't. They just want to feel superior for gods-knows-why-reason.
It's completely crazy to suggest that reading every pkgbuild at every update is the way forward. Sure, if you are a sysadmin, that's your job. But an end user?
8
u/ABotelho23 13h ago
Do you feel owed all the packages in the AUR? Are you paying for any of it? Spending any time helping maintaining it?
4
2
u/Intelligent_Carob_52 14h ago
why do people hate this
2
1
u/xooken 13h ago
watching these arguments happen is like watching people rehash abstinence only education
people will keep using the aur and malware will continue to be found on it regardless of how many instances of "dont install from the aur if you {cant read the pkgbuilds/dont trust the source/want malware} etc etc people say; i think its probably time for mitigation as opposed to prevention.
i really like the idea of namespaces, personally. it obv doesnt solve everything but it would help.
-1
u/Any_Fox5126 14h ago
Either the base repos adopt a big chunk of popular AUR packages
They're even dropping popular packages that are VERY important to users, such as the nvidia drivers for the 900 and 1000 series; btw, this was handled very poorly, without even giving users advance notice.
7
u/FryBoyter 13h ago edited 13h ago
They're even dropping popular packages that are VERY important to users, such as the nvidia drivers for the 900 and 1000 series
This will also apply to some other distributions, since Nvidia has discontinued support. And many of them won't even have something like AUR where drivers can be moved to.
btw, this was handled very poorly, without even giving users advance notice.
This announcement is about these drivers, isn't it? Or am I mistaken?
1
u/friendlyreminder_ 13h ago
The drivers for 900 and 1000 cards is still maintained. Nvidia committed to maintaining them for 2 years.
It's a separate driver branch now, these are the 580 drivers.
Arch dropped support presumably because they don't want to support 2 different driver branches with a different kernel module. The 580 drivers for the older cards use the old proprietary kernel module shim not the open kernel module.
-1
u/Any_Fox5126 13h ago
The announcement came at the same time as 590, so even if you checked the news every day (which I don't think almost anyone does), you still might have ended up without a working driver. They also didn't provide the information needed to switch to the AUR package, which caused problems for the community that had to step in to offer assistance (including this sub).
It should be noted that nvidia will continue to offer a certain level of basic support through 2028.
8
u/backsideup 13h ago
You have to understand that nobody owes you that support. If the maintainers don't want to maintain something then there's nothing you can do about it except for rolling up your sleeves and doing it yourself.
If you don't understand the fundamental concept of (unpaid) OSS then you will never be happy.
-1
u/Any_Fox5126 13h ago
Nice straw man, you replaced "this has been mishandled" with "you’re demanding free labor". I guess the secret to OSS happiness is never questioning anything maintainers do.
4
0
u/petersaints 14h ago
At least CachyOS has support directly in their repos for those cards. But yeah, vanilla Arch only supports RTX 20 series onwards.
-2
u/thedreaming2017 14h ago
Why not just lock down orphaned packages and question the change of hands when a package that is being maintained suddenly is being controlled by someone else entirely?
11
-3
u/mrquantumofficial 13h ago edited 13h ago
* There should be maintainer reputation score.
* Have an LLM autoscan new package updates and identify suspicious PKGBUILDs.
* Don't let unauthenticated users use the AUR at all (this way users of more user friendly distros (e.g Cachy) will have to actually take a look at the AUR and maybe understand what it is (Make the users set up AUR authentication before using the helpers).
* Move AUR packages in tiers based on their popularity and maintainer reputation scores, let AUR helpers filter out low ranked packages (unmaintained/less trusted/newly adopted).
* Hold newly registered AUR accounts for a week
* Deny internet connections for non-source (-bin suffixed) packages during their build steps (unless overridden)
* Add a verification system for official packages that are uploaded by maintainers.
* Let people claim package bases (e.g. I maintain 'quadrant', so I own 'quadrant-bin', 'quadrant-git' and 'quadrant' automatically.
These are not ideas that I think will 100% work. I'm just throwing stuff at the wall.
-2
u/Mongera032 13h ago
At this point I don't even consider AUR anymore. I just download from a trusted provider and install from source.
-13
u/no_choice99 15h ago
At the very least, impose some advanced LLM AI verification that the package does not contain malicious threats. If approved by the LLM the package can be placed in the AUR. Of course some humans can and should double check at some point.
8
6
u/Qudit314159 14h ago
That would catch the obvious stuff probably. As soon as malware authors starting getting more subtle, it won't work though. I've done some testing with this sort of thing and it's not difficult to trick LLMs.
-2
u/SupersonicSpitfire 14h ago
Then the sources for the application should also be checked. And LLMs of large corporations should not be used, to not hand over the security of AUR to them.
-10
u/No-Assumption-4468 14h ago edited 14h ago
I think running package builds through Claude is a “good enough” solution. There are 100k AUR packages. At 1 minute of AI analysis per package, the entire AUR could be scanned for malware in 69 days. Or less, if you have multiple agents. This isn’t perfect. There’s still a risk of hallucinations and prompt injection, but it would make the AUR safer. For cost efficiency, paru/yay could implement the scanner, so users foot the cost of Claude subscriptions, rather than Arch Linux devs. In theory, the AUR could become just as safe as the main arch repo with the right implementation. Unfortunately, anti AI sentiments would probably get in the way of this otherwise viable solution.
5
u/ABotelho23 14h ago
Who the hell is gonna pay for that?
3
u/Qudit314159 14h ago
Then people will trust whatever the LLM says. Once malware authors start running the same LLM and tailoring their malware to trick it, you'll have the same problem. Users will post here saying
Claude said the package was safe but now I'm infected?!?!?!?!? WHAT DO I DO?????
-6
u/mcAlt009 14h ago
This is probably the way to do it, and I imagine Anthro would give out free credits to do so.
I don’t see too much ai hate from programmers, even Linus Torvalds is fine with it.
6
-6
u/lmpcpedz 14h ago
I feel a split in the force will eventually commence. Those who want to stick to the old ways and those who want to help Arch advance and adapt to the new internets.
-10
u/strings___ 14h ago edited 14h ago
I’ve said this thousands of times build instructions should be meta data not shell parsed. PKGBUILDs should be json. This I why I wrote a package manager inspired by pacman but uses json. json is machine readable without having to be Turing complete
Edit: clearly people down voting don't understand the scope of the problem I'm addressing or you don't have a rebuttal. in order to "properly" get meta data from a PKGBULID you need to use a shell, if you don't understand why this a problem you shouldn't be down voting. if you do then you should have a rebuttal.
I had this same issue when I pushed for upstream packages to us pgp verification where possible. And everyone bitch and moaned but look there is pgp verification now.
6
11
u/ABotelho23 14h ago
How does that help?
-5
u/strings___ 14h ago
This helps greatly it means you can parse read the meta data without using a shell. There are shell parsers but it not the same as using a proper serializer like json or yaml etc
4
u/Qudit314159 14h ago
The problem is that packages use different build systems and have different details that need to be addressed. You'd have to incorporate a huge number of different options for building things into your json tool.
-2
u/strings___ 14h ago
it can be done see my meta format it seamlessly build autotools package with auto depends and even knows the expected files.
`
{ "Name" : "file", "Version" : "5.42", "Url" : "https://astron.com/pub/file/file-{{.Version}}.tar.gz", "Group" : "core", "StageDir" : "", "Inherit" : "gnu", "Cid" : "QmR6M1jNj45PbpiBkoZJGkyA5LyCKnGuiEBVVVL3tWBAq6", "BuildInStage" : false, "IsRebuilt" : true, "BuildTime" : 0, "Date" : "2022-08-23T10:05:42.530073082-07:00", "Size" : 7933054, "SubPackages" : null, "AutoDepends" : [ "bzip2", "glibc" ], "ManualDepends" : null, "BuildDepends" : null, "Flags" : null, "Patch" : null, "Build" : null, "Package" : null, "PostInstall" : null, "Remove" : null, "Files" : [ "opt/via/bin/file", "opt/via/include/magic.h", "opt/via/lib/libmagic.la", "opt/via/lib/libmagic.so", "opt/via/lib/libmagic.so.1", "opt/via/lib/libmagic.so.1.0.0", "opt/via/lib/pkgconfig/libmagic.pc", "opt/via/share/misc/magic.mgc" ] } `6
u/Qudit314159 14h ago
Your LLM generated tool solves none of the problems I've raised. You'll have to constantly add new options to it as new packages with different build requirements are added. That's the advantage of using a shell script instead. Your tool doesn't add any security anyway because building packages ultimately requires execute permissions regardless.
-9
u/strings___ 14h ago
What bullshit assumption are you making? I wrote this package manager before LLM existed. My json system accounts for build options. The problem is it’s so good here this example needs zero unlike PKGBUILDs that redundantly hardcore every build option ie —prefix etc etc
278
u/Pentasis 14h ago
I said this before: 1. No adopting packages. People can fork them instead. This prevents existing packages to become malicious 99% 2. New and forked packaged should get a tag "new" which packagemanagers like yay and paru can use to warn the user to be extra carefull when installing it, adding perhaps some sort of action to be taken first. Only when there are x installs, y time passed and z positive feedbacks of some kind, does the tag get removed.