How (and not) to fix the AUR

lightdot · 2026-08-07 13:30:32

seth wrote:

@cryptearth
... Hence the idea to enforce the requirement to review the PKGBUILD by systematically breaking them. Everybody who cannot or does not want to deal with that is simply better off not using the AUR (which they then no longer can) ...

I see a... khm... couple of issues with this idea, although I honestly find it wonderfully provocative.

So, if I understand correctly, either:

- an automated system would introduce "breakage" during the PKGBUILD submission, a flawed PKGBUILD would be committed into the AUR's git.

or:

- the correct PKGBUILD would be committed, "breakage" would be introduced during the PKGBUILD delivery to the AUR user.

The former would introduce various workflow challenges, the latter would mandate a closed, private git for AUR, with just a jesting API, coloring the PKGBUILDs with all possible colors of the rainbow.

In any case, be it the first or the second approach, at this point we might need to temporarily shut down the AUR comment section, the BBS, IRC, and Reddit for good measure, as there would be mayhem. "Temporarily" might be wishful thinking. The AUR comment section would be permanently flooded from that point on.

Then there is the question of the extent of the "breakage". The system introducing it would need to be either very complex, or it would need to introduce a very trivial "breakage" so that all kinds of PKGBUILDs can indeed be reliably "broken" but still usable by an average user, after a moderate intervention.

But it can't be that trivial either, or at least a few AUR "helpers" would soon be "improved" to deal with it automatically.

In any case, at this point someone would make a "clean" AUR git copy somewhere, and AUR as such would go down in flames with a slightly less of an audience. This new instance would likely grossly underestimate the task at hand, and all in all, it would be a dumpster fire, dividing the community with very questionable outcomes.

So we might just shut AUR off to begin with... Which I'm not advocating for, just to be clear!

On the positive side... I don't have a very optimistic view on the benefits of coercing the users into actually reading the PKGBUILDs in the first place, if they don't really want to. But let's assume it worked...

...so, the PKGBUILDs are wonderfully broken, users study them... but what are they looking for? For "breakage" itself, for the minimum that needs to be done so that the package builds. I really don't see them looking for much else, or suddenly gaining an ability to successfully recognize a subtle but malicious trojan, if they didn't want or knew how to do it to begin with.

To add to this flaming mess, some users would likely unleash schizophrenic LLMs on the PKGBUILDs just to make them build, with very mediocre prompts and grim outcomes. And it would all burn and fall apart with even greater pizzazz.

I know, I know, I'm overly optimistic today but I just don't see this path leading towards AUR's bright future...

seth · 2026-08-07 16:25:24

"nasty details"

The point however is that the current vandalizations "work" by scaring users w/ a diffuse "thread" scenario that does not work against anyone paying minimum attention to the process.
A userbase that's used to and expected by anyone to provide this attention (ideally, that's the theory) disincentivises such follies because "I posted some shit in some public space and nobody cared" is hardly something to phone home about.

This is not meant and will not enable anyone to spot hyper-sophisticated actual package compromisations, no matter how intensely they read the PKGBUILD.
This is generally not possible, if the NSA spends a billion dollars on tricking me, there's like a 1-2% chance they'll actually pull that off

The catch needs to be injected at distribution, otherwise you're running into problems w/ the author pushing commits and also they'd be public, so easy enough to be avoided by AUR helpers.
It will also prohibit the (automated) creation of a "clean" clone, because you're only getting "dirty" PKGBUILDs
Unrelated to that it's of course not possible to prevent the creation of a completely alternative AUR infrastructure - which however would then be in the situation the actual AUR is currently.

About the noise in forums and comments, the breakage is meant to be accompanied by a clear enough message that will also provide a lead to its origin in the PKGBUILD.

Keeping the bogus function obvious enough to not be a hurdle for human AUR users but obfuscated enough to evade (non-AI driven) countermeasures of the AUR helpers and also clean enough to not cause merge conflicts (because I'd consider that a showstopper for regular AUR users, merge conflict resolution sucks for habitual git users) is no doubt gonna be the tricky part of the nasty details; tbd if this approach is entertained.

lufog · 2026-08-07 18:24:50

I might be saying something stupid here, but I'm picturing something like adding a hidden "trusted" field to user accounts. It would automatically activate for accounts that, for example, are older than six months and show some activity, and deactivate after a long period of inactivity. The idea is that in case of malicious activity in the AUR, permissions could be temporarily restricted for all new/"untrusted" accounts without affecting the "trusted" ones. This wouldn't completely fix the problem, but it would at least reduce the collateral damage.

Last edited by lufog (2026-08-07 18:25:27)

seth · 2026-08-07 18:58:06

There's no necessity to maintain a flag on that - you could just poll that data (age, last login) when deactivating accounts.
But I suspect individual account handling would take too long in an "emergency" shutdown anyway.
It would also not help in a case of data breach (ie. if users re-used the password and got exposed by some database leak elsewhere) or sleeper accounts.

And it would also only address a shutdown after an incident, not prevent such incidents from being a thing.
(Which they objectively are not: some assholes very transparently added extremely obvious malware to some stale packages nobody cared enough about anymore to maintain them - this is always a possibility w/ an open sharing system and really should™ not freak out anyone)

aminepro · 2026-08-07 20:01:53

That sucks, people should be less elitist. In some cases (not talking about you!) I understand though: sometimes you read the same question a millionth time on the same day and get a bit peeved because there is a search function.

I got an idea!
I thought if we can have pkgbuilds typed like a programs with a new programming language that doesn't compile if not the specified keywords are used and for the links have a repository of permitted links that are trusted and only if the used links aren't trusted we'll inspect it, the pkgbuild wouldn't be a program though the programming language is just a description.

Maybe not have a new programming language but at least limit the commands that can be used, does that sound good? (I'm not serious or anything I barely use the aur already recently, but I'd like explanations if I don't get something.)

seth · 2026-08-07 20:27:38

Build and installation of generic sources will require various shell and system commands - it is not possible to restrict that at the package generation recipe.

Who trusts those links based on what?
The AUR packages all sorts of stuff, but how do you even determine ex ante which github repos are "trusted" (for what and by what standard)?

You'll not get to a point where users can apply blind trust to any PKGBUILD in the AUR.

You can (though should™ absolutely not) decide that you're gonna blindly trust a specific AUR maintainer and all their packages (which would be equivalent to getting those PKGBUILDs from that individuals github repo or private server) but that creates the problem "how do I know which AUR maintainer I trust?"
If your answer to that is "Oh, the arch developers could say that they trust that AUR maintainer" you've replicated t he trusted-user concept and are about to turn the AUR into an official repo (which that trusted AUR maintainer now could submit to)
=> See "How to NOT fix the AUR", item #2

Edit: because you seem to struggle with that - it is ok to bring those ideas up and you're also entitled to disagree and argue your case if you suspect flaws in my (or anyones) reasoning.

Last edited by seth (2026-08-07 20:33:40)

aminepro · 2026-08-07 21:01:46

Edit: because you seem to struggle with that - it is ok to bring those ideas up and you're also entitled to disagree and argue your case if you suspect flaws in my (or anyones) reasoning.

Thanks

Build and installation of generic sources will require various shell and system commands - it is not possible to restrict that at the package generation recipe.

I just thought about it being a framework where everyone can learn it and start to use like having a standard, of course it should be complete that's why I made the programming language analogy.

Who trusts those links based on what?

Make a text file of links that link to harmless code based peoples experiences (votes?) someone try it first before suggest it to be submitted the community looks at it and say it is worth it.

The AUR packages all sorts of stuff, but how do you even determine ex ante which github repos are "trusted" (for what and by what standard)?

Users check constantly, use tools if needed like virus checkers or llms on their own then say that this link is worth being in that links file.

You'll not get to a point where users can apply blind trust to any PKGBUILD in the AUR.

Ofc not, maybe one should build his own links file and maintain it that is primarily for making it easier for yourself to check what you install, understand the language and create you're repository of links and keep building on your past progress.

You can (though should™ absolutely not) decide that you're gonna blindly trust a specific AUR maintainer and all their packages (which would be equivalent to getting those PKGBUILDs from that individuals github repo or private server) but that creates the problem "how do I know which AUR maintainer I trust?"

maybe users would start sharing their repositories of links to others to copy it, check it for untrusted links, ...)

If your answer to that is "Oh, the arch developers could say that they trust that AUR maintainer" you've replicated t he trusted-user concept and are about to turn the AUR into an official repo (which that trusted AUR maintainer now could submit to)

I'd like to see it primarily for making playing with pkgbuilds available to everybody so they choose their faith, if they choose to trust someone that's their problem, but in the other it would be hard to get bad links cause there is just many users.

=> See "How to NOT fix the AUR", item #2

OK, now
Basically I'm talking about how to make the PKGBUILD script and how to make it something that can use more men power
I noticed some inconsistency on my writing, calarify it here:
there may be a shared repository of links but this is just for ones that everybody use.

seth · 2026-08-07 21:49:50

use like having a standard

You need to look at some PKGBUILDs to see how the sausage is actually made
There's no standard way to build or install programs, upstream programs are build w/ various configuration and build tools, compilers…
They sometimes needs patches or just sed-fix a line after the configuration (ie. after the patches are applied)
Then there's the installation which either can use a Makefile or the install command.

someone try it first before suggest it to be submitted the community looks at it and say it is worth it

You're describing the AUR.
Someone™ (the author of the AUR packge) suggests to build some upstream project and then the community™ (users interested in that upstream project) read the PKGBUILD, have a look at the upstream and figure "that's ok with me"
There's even a voting system, but voting is easily gamed and cannot serve as the basis of any trust - if gives you an indication what packages are likely popular - not about the veracity.

maybe users would start sharing their repositories of links

How do you know that you can trust the user who tells you to trust that AUR package over there?

Shifting the trust level (instead of trusting A you will trust B who tells you to trust A) will get you nowhere, limiting it (you trust A, B and C and nobody else) will replicate the repos and cascading it (you already trust A, A trusts B and C, B trusts D and E…) does not provide reliable trust (you trusted A and by inference E, but E is evil - A trusted B but B was fooled by E) and is prohibitive (new AUR contributors aren't trusted by anyone and who would rely on an unstrusted maintainer? So how do they build reputation to gain some trust?)

Repeat after what seth wrote:

You'll not get to a point where users can apply blind trust to any PKGBUILD in the AUR.

People are twisting their brain into pretzels just to maybe find a way to lure themselves into believing they won't have to actually pay attention to what they're doing there and can just treat it like the official repo they want it to be.
Rather use that brain energy to just check the PKGBUILD - much more effective.

loqs · 2026-08-07 22:29:49

seth wrote:

There's no standard way to build or install programs, upstream programs are build w/ various configuration and build tools, compilers…
They sometimes needs patches or just sed-fix a line after the configuration (ie. after the patches are applied)
Then there's the installation which either can use a Makefile or the install command.

All true. While there are standard ways for autotools, cmake, meson ..... you certainly need a way to run arbitrary commands to fix up all the none cookie cutter packages. You can constrain the locations where those commands are run to fixed overrides for each part of the build process rather than bash allowing anything to be overwritten any number of times from anywhere in the script.

aminepro · 2026-08-07 23:28:18

"I didn't change the way I'm writing cause I'd rather provide the way of thinking than changing the initial thoughts just to make more perfect text at the expanse of making a puzzle on how the idea came to its final form, I want to patch gaps in my understanding after all" that's what I said to myself.

You need to look at some PKGBUILDs to see how the sausage is actually made wink
There's no standard way to build or install programs, upstream programs are build w/ various configuration and build tools, compilers…
They sometimes needs patches or just sed-fix a line after the configuration (ie. after the patches are applied)
Then there's the installation which either can use a Makefile or the install command.

Can we make a language that translates form/to bash just to do the processing so we can apply a standard that we invent

someone try it first before suggest it to be submitted the community looks at it and say it is worth it
You're describing the AUR.
Someone™ (the author of the AUR packge) suggests to build some upstream project and then the community™ (users interested in that upstream project) read the PKGBUILD, have a look at the upstream and figure "that's ok with me"
There's even a voting system, but voting is easily gamed and cannot serve as the basis of any trust - if gives you an indication what packages are likely popular - not about the veracity.

Maybe, but that's not the intention, that was me still thinking about it, the best advantage would be building on past progress as you build a links files (not necessarily repository) which a program like pacman would use to see if that package applies to the standard and the framework, the framework where use of only harmless commands, for the complex sed usage cases or such you'd get a warning to look it up. Again even though that may seem like automatizing the installation entirely I'm talking in theory about the perfect scenario just to get the idea, patch it later with how that makes reading the pkgbuilds easier not emit reading it yourself entirely.

How do you know that you can trust the user who tells you to trust that AUR package over there?

I wasn't talking about aur packages yet, it's about the links that completes the framework (use the programming language's keywords and the so trusted links to make a package users in the other side have their own trusted links and would add theirs after trusting by investigating them making the process easier for everybody getting exactly to where you need to expand you're knowledge to continue.
Conclusion
what is being debated about being trusted or not is the code itself (links)
the framework runs trusted code just like a compiler compiling correct code. <= that seems to be the not likely to happen part
users build on their past work and don't necessarily understand everything from the start, links files are easier to fix (maintain) and if you're installing some package that a few use and have untrusted links by you look them app by reading if you have the knowledge, asking others, using tools I stated earlier to understand what the code is doing.
Note
the pacman like program that I just imagined isn't the main idea, this is about pkgbuilds that are made with the framework that uses trusted links to make the pkgbuild usable at the first place, so what's needed is a Standard that I really have no knowledge about how it can be done.

aminepro · 2026-08-07 23:39:26

People are twisting their brain into pretzels just to maybe find a way to lure themselves into believing they won't have to actually pay attention to what they're doing there and can just treat it like the official repo they want it to be.
Rather use that brain energy to just check the PKGBUILD - much more effective.

You're right things are getting a bit too complicated

NidoBr · 2026-08-07 23:54:03

The AUR is based on “trust” between users and on the idea that all users understand and are responsible for dealing with the risks involved in using it, but we know that only a minority actually checks what they are installing.

As long as the AUR continues to rely on user behavior, there is not much that can be done while preserving its current level of freedom. I am not saying that this freedom should be taken away from the AUR, but dealing with this kind of problem is complicated. If it were purely a technical issue, a logical solution would be enough, but when we are dealing with people, things are not that simple...

seth · Yesterday 06:30:07

aminepro wrote:

Can we make a language that translates form/to bash just to do the processing so we can apply a standard that we invent

No. There is no standard to be had here.
As loqs points out you can somewhat control the environment (though I'm not sure that includes system calls - god knows what makefiles, installation scripts etc. are doing) but there's no point in inventing a new language that maps complete shell access to just a different kind of complete shell access.

a program like pacman would use to see if that package applies to the standard and the framework, the framework where use of only harmless commands…

I frankly have no idea what you're trying to say there, but pacman has nothing to do w/ the AUR or package building process (save that makepkg can optionally invoke it to immediately install the just built package locally)

what is being debated about being trusted or not is the code itself (links)
the framework runs trusted code just like a compiler compiling correct code. <= that seems to be the not likely to happen part

That boils down to whether what's packaged is what's advertised, but there's simply no way to generically or ex ante know that and people might even disagree whether that's the "correct" fork or even software category, see eg. https://bbs.archlinux.org/viewtopic.php?id=314506
And the question whether the packaged upstream is trustworthy (ie. free of malware) is a problem WAY beyond the scope of the AUR - you cannot even guarantee that for packages in the official repos - or at all. I frequently wonder whether <unnamed desktop environment> is malicious or just that incompetent

NidoBr wrote:

we know that only a minority actually checks what they are installing … we are dealing with people, things are not that simple...

seth in the OP wrote:

Systematically vandalize PKGBUILDs w/ a git hook by randomly shadowing (early) functions like verify() or build() to print a clear enough warning and exit makepkg.
This isn't a major problem to proper users: the PKGBUILD is still fully intact (a later function will replace an earlier one w/o the need to remove the latter from the file), the message can be made easy to spot (some all-caps part) and the function removed when inspecting the PKGBUILD.
Everyone else can have a jump scare and blind-trust automated builds using a helper won't work.

aminepro · Yesterday 10:43:03

That boils down to whether what's packaged is what's advertised, but there's simply no way to generically or ex ante know that and people might even disagree whether that's the "correct" fork or even software category

No, because if we depend on links used in the package build then we are looking for something more fundamental than a package, what you'll be reading isn't just the pkgbuild but investigate the new links, I just realized that I wasn't talking about the case of an update( if you need that check the links that updated the code they link to in a repository specific for that ), you know exactly what you are installing, it's that installing anything from the internet would be dependent on the internet in other word in case of update you need to maintain your links repository as expected by using the community, since others would do the same so you can build on their work, if all the links in your file became untrusted you go to the internet to make a new one, it's not that you trust others but you trust yourself deciding what to trust depending on how many found the same result and other factors...
the links would be defined using checksums of what they link to.

Last edited by aminepro (Yesterday 11:57:40)

NidoBr · Yesterday 11:40:47

Given that we cannot eliminate the freedom that defines the AUR, I believe we should presume negligence on the part of the user and work on ways to minimize harm should something go wrong.

seth · Yesterday 14:32:30

aminepro wrote:

No, because if we depend on links used in the package build then we are looking for something more fundamental than a package, what you'll be reading isn't just the pkgbuild but investigate the new links, I just realized that I wasn't talking about the case of an update( if you need that check the links that updated the code they link to in a repository specific for that ), you know exactly what you are installing, it's that installing anything from the internet would be dependent on the internet in other word in case of update you need to maintain your links repository as expected by using the community, since others would do the same so you can build on their work, if all the links in your file became untrusted you go to the internet to make a new one, it's not that you trust others but you trust yourself deciding what to trust depending on how many found the same result and other factors...
the links would be defined using checksums of what they link to.

Do you use a translation service to generate these texts?

What links in what file?
Who generates that file?
Who vouches for its contents?
Why would you trust them?
Where does the necessary information to sign off on the contents of that file come from?

And what does that ultimately achieve?
If you wanted to ensure the source url is legit, why would you not simply visit the source and see whether it's what you intend to install?

twelveeighty · Yesterday 15:02:16

@seth: I don't have any objections against your suggested solution, but in my opinion your solution is no different from the "do nothing" approach, and therefore "why do something if you could just do nothing?". In fact, why even turn off access and new account creation and instead just "let it ride"?
The ONLY solution is that users check and vet downloaded PKGBUILDs.

I wonder if we can't "let it ride" because the AUR is (still) too closely "related" to Arch Linux from a legal standpoint and therefore a liability if someone sues Arch for damages inflicted by a malware AUR package. (Let's not get into jurisdiction, most countries have liability laws). That link is hard to sever, with TU / package maintainers arguably "maintaining" both Arch and AUR and pushing packages up and down from the AUR into Arch. Even if the AUR name, logo, artwork, etc. is completely changed. Perhaps that is the true issue to be resolved, not the malware itself.

aminepro · Yesterday 15:17:11

Do you use a translation service to generate these texts?

that hits hard, No why is there a problem with my english? please point out where my text seems weird to you so I can improve it

For your questions, I supposed you're keeping with everything I posted, but you seem rather wanting to build on the current form of pkgbuilds as they are now, my intention is to make it different by not having a certain mainter people rely on but rather have everybody knowing what they are doing to a basic level making it easier to learn as you think you're taking more serious risk to your system, I also said that I'm still not making everything consistent yet because I want this as a discussion, I'm not worthy of lecturing or anything, to point out the most important ideas so far:
Any pkgbuild that doesn't have certain criteria is useless if you want to install it through the framework
The framework makes sure that there can't be a harm in the installing commands themselves, and for the links used to get code from the internet there's a file that contains many links with hashes to the source code they link to.
The links file is one's responsibility to maintain but as we know that's hard for everyone to do, especially that the main idea behind this change is use the whole community not just maintainers to make sure everything serves its purpose, I said " use more men power" before.

seth · Yesterday 15:24:15

@1280

The entire AUR policy is basically one big "caveat emptor" to shield arch from any liability wrt what joe user does to their system.
I suspect that's one of the reasons why arch could never announce eg "we're now scanning every package for malware" because at that point you'd really have shared responsibilities and a legal quagmire.

The proposed solution does not seek to do anything to protect users but to change the ecosystem by forcing users to habitually review the PKGBUILD and therefore pay attention to what they're doing when installing stuff from the AUR.
This altered ecosystem does not allow to spread FUD through blunt vandalization waves and will hopefully stop them for now being lame.

I don't think we can let it ride because
1. the public chicken yard these incidents currently cause and probably will continue to cause
2. the AUR is actively moderated and maintained - once the maintainers are made aware of ongoing situations such as the current they probably *have* to take action to avoid liability through active neglect

@aminepro

Please lay out what you envision that "framework" to look like and how it "makes sure that there can't be a harm in the installing commands themselves"
I had hoped to have conveyed that that's probably a fantasy.

Edit: if you think of some system where one defines

buildsystem=cmake
config_options=(WITH_FOO NO_BAR SNAFU=5)

and that then auto-generates a basic PKGBUILD that runs "cmake -DWITH_FOO -DNO_BAR -DSNAFU=5; make; make install" that is possible but of limited use because it will create a trivial PKGBUILD you could read just as easily and can only be used for a small subset of upstream software that actually adheres to those trivial build steps in a common flavor (cmake, meson, autotools, …)
The PKGBUILDs that are actually hard to read can not be addressed this way.

Last edited by seth (Yesterday 15:52:25)

aminepro · Yesterday 15:53:44

Edit2:

Please lay out what you envision that "framework" to look like and how it "makes sure that there can't be a harm in the installing commands themselves"

a set of rules that restricts the commands, the paths it uses depending on the type of the package and other factors, so we classify packages for the purpose the process more flexible it shouldn't be that big of a deal to use and understand for new users but also make it difficult to get trapped.
the whole methode I envision doesn't include a choice of ignorance, you want to install something then you should what that thing is what is it doing where it came from, and it's rewarding because you learn as you go and build on your past experiences, it's complex because it relies on many factors and it is NOT independent you can't just install using pacman -S, you interact with the community, ask, read, investigate yourself. making it difficult to be attacked because how you trick someone through many layers of protection the difficulty becomes exponential

I had hoped to have conveyed that that's probably a fantasy.

Yeah you said something like that
I just wanted to give more ideas so who knows, maybe apply to an extent to limit the harm.
wait a minute I didn't ask why yet, you said something about the complexity of some commands ex sed but how can any serious harm in the pkgbuild not be detected and how there can't a be a safer option to install a package, installing should do one thing after all make it work nothing more if anything doesn't serve that it is harmful "commands"?

edit:

Edit: if you think of some system where one defines
buildsystem=cmake
config_options=(WITH_FOO NO_BAR SNAFU=5)
and that then auto-generates a basic PKGBUILD that runs "cmake -DWITH_FOO -DNO_BAR -DSNAFU=5; make; make install" that is possible but of limited use because it will create a trivial PKGBUILD you could read just as easily and can only be used for a small subset of upstream software that actually adheres to those trivial build steps in a common flavor (cmake, meson, autotools, …)
The PKGBUILDs that are actually hard to read can not be addressed this way.

That's I've dealing with so far I only have three packages that I built from the aur

ls builds/aur/
ab-download-manager/  j7z/  vanilla-wiiu-git/  ventoy/  ventoy-bin/

(three I use) the rest is from its source.

Last edited by aminepro (Yesterday 16:18:05)

Lone_Wolf · Yesterday 16:08:51

The commands are not harmful by themselves it's their use that can be harmful.

an example is the dd command :
It can be used to create a bootable usb stick with the archlinux iso on it or make a backup copy of a problematic drive both of which are helpful .

However using it with if=/dev/zero and of=/dev/nvme0 will very likely make your system unbootable and is HARMFUL.

Last edited by Lone_Wolf (Yesterday 16:09:51)

tridra · Yesterday 16:14:03

I'd be okay with the idea of having to solve a minigame when you install/update a package, it would certainly discourage some people from doing things that they shouldn't do. But I'm a bit less favorable to the idea of deleting orphaned packages, mostly because it's work that has already been done, and if I wanted to install those packages or even make a PKGBUILD for myself I won't have to start from scratch.

Anyway, this is what I've been thinking as a possible long term solution:

Building a chain of trust of verified users

This would be just a checkmark next to someone's username, a boolean that AUR helpers could check and notify users.

How would verification work?

The first users would need to be verified by AUR mods, then when someone is verified, they can verify other users.

What would verification consist of?

Verified users would have to follow some guidelines when they grant verified status to another user. Something like reviewing the packages they maintain, how long they've been maintaining them etc.

What happens if a verified user does something malicious?

Beside the attacker, the user who verified them would also lose their status. When a user loses verified status, the chain of trust breaks and everyone else who they've verified loses their status too. If, after review, other users above in the chain of trust are deemed responsible (in case someone was using multiple sock puppet accounts), they can also lose status and chain of trust. This would make sock puppet/bot accounts less effective and more easily identifiable.

Gaining and losing verified status needs to be part of a user's public history, as well as who granted them verified status and who they granted verified status to. This would mean lots of people who were not involved in an attack would also lose their verified status. They can get verified again by someone else, but whoever was at the top of the chain of trust and was deemed responsible for granting verified status to a user that turned out to be an attacker would need their case to be reviewed by AUR mods.

What if someone can't get verified?

Verified users would have exactly the same privileges as unverified users, no difference other than the checkmark next to their username.

What problem would this solve?

This is intended as a long term solution that would lay the groundwork for a system where verified users could voluntarily participate in the moderation effort with limited powers, similar to Wikipedia's tiered system. In this case it would be: AUR mods > verified users > unverified users.

Users who don't want to read PKGBUILDs will still be a thing, let's call them "vibe users." They'll likely care even less about reading PKGBUILDs if they stick to packages from verified users, but that also means they'd be harder to reach by random attackers/vandals, making potential attacks that use the current patterns even more inconsequential. And if vibe users become harder to reach, attackers would have less incentives to put malware on the AUR, so everyone would benefit from this.

In the short term this can't address vandalism, but if the network of verified users grows enough, verified users could approve adoption of orphaned packages if an unverified user wants to adopt a package.

seth · Yesterday 16:50:47

@tridra

seth wrote:

Shifting the trust level (instead of trusting A you will trust B who tells you to trust A) will get you nowhere, limiting it (you trust A, B and C and nobody else) will replicate the repos and cascading it (you already trust A, A trusts B and C, B trusts D and E…) does not provide reliable trust (you trusted A and by inference E, but E is evil - A trusted B but B was fooled by E) and is prohibitive (new AUR contributors aren't trusted by anyone and who would rely on an unstrusted maintainer? So how do they build reputation to gain some trust?)

Does any single socially engineered abuse of trust (think of the xz situation, somebody playing white knight for the long game) explode the entire trust cascade?
What if a verified users account gets breached? S/hit/he/fan?
How many (other) AUR contributors (that are not already "trusted users" as in Arch repo commit rights) do you know you'd personally vouch for?
Do you think this might lure users who are currently doing their due diligence and review the PKGBUILD before running it into getting a bit lazy?

tridra · Yesterday 17:26:19

Does any single socially engineered abuse of trust (think of the xz situation, somebody playing white knight for the long game) explode the entire trust cascade?

I think social engineering will always be the weakest point. The idea is to reach a point where if someone wants to attack the AUR they'd have to put much more effort and resources into it.

What if a verified users account gets breached? S/hit/he/fan?

It would be no different than the current situation.

How many (other) AUR contributors (that are not already "trusted users" as in Arch repo commit rights) do you know you'd personally vouch for?

I don't have to. I can look at someone's history and if for the past year they've been updating the packages they maintain without doing anything malicious, I'd vouch that they're doing what they're supposed to be doing. If they, after they get verified, push malware, both they and I would lose verified status (and they'd be banned of course).

Do you think this might lure users who are currently doing their due diligence and review the PKGBUILD before running it into getting a bit lazy?

Yes, it's a risk. Honestly I think that even having a "verified user" checkmark would be too much to build fake trust. Maybe doing the opposite, a label "not verified" by default for everyone would be better.

seth · Yesterday 18:40:10

I think social engineering will always be the weakest point

Yes, but what happens to your trust cascade once somebody turns out to be evil?
From your description you'd wipe the entire tree (subsidiaries get distrusted, but also the parent loses its trust - so their other subsidiaries ie. the siblings of the evil actor get wiped all the way down. And does the grandparent get punished because their child signed off on a malicious actor?)

It would be no different than the current situation.

The current situation has no "verified user"? Everyone's equally suspicious.

I don't have to. I can look at someone's history and if for the past year they've been updating the packages they maintain without doing anything malicious

So what's the difference between you and an algorithm rating someone as trustworthy because they've X aur commits w/o being flagged for being evil?

Arch Linux

#26 2026-08-07 13:30:32

Re: How (and not) to fix the AUR

@cryptearth

#27 2026-08-07 16:25:24

Re: How (and not) to fix the AUR

#28 2026-08-07 18:24:50

Re: How (and not) to fix the AUR

#29 2026-08-07 18:58:06

Re: How (and not) to fix the AUR

#30 2026-08-07 20:01:53

Re: How (and not) to fix the AUR

#31 2026-08-07 20:27:38

Re: How (and not) to fix the AUR

#32 2026-08-07 21:01:46

Re: How (and not) to fix the AUR

#33 2026-08-07 21:49:50

Re: How (and not) to fix the AUR

#34 2026-08-07 22:29:49

Re: How (and not) to fix the AUR

#35 2026-08-07 23:28:18

Re: How (and not) to fix the AUR

#36 2026-08-07 23:39:26

Re: How (and not) to fix the AUR

#37 2026-08-07 23:54:03

Re: How (and not) to fix the AUR

#38 Yesterday 06:30:07

Re: How (and not) to fix the AUR

#39 Yesterday 10:43:03

Re: How (and not) to fix the AUR

#40 Yesterday 11:40:47

Re: How (and not) to fix the AUR

#41 Yesterday 14:32:30

Re: How (and not) to fix the AUR

#42 Yesterday 15:02:16

Re: How (and not) to fix the AUR

#43 Yesterday 15:17:11

Re: How (and not) to fix the AUR

#44 Yesterday 15:24:15

Re: How (and not) to fix the AUR

@1280

@aminepro

#45 Yesterday 15:53:44

Re: How (and not) to fix the AUR

#46 Yesterday 16:08:51

Re: How (and not) to fix the AUR

#47 Yesterday 16:14:03

Re: How (and not) to fix the AUR

#48 Yesterday 16:50:47

Re: How (and not) to fix the AUR

#49 Yesterday 17:26:19

Re: How (and not) to fix the AUR

#50 Yesterday 18:40:10

Re: How (and not) to fix the AUR

Board footer