On 5/27/26 5:11 PM, Claudia Pellegrino wrote:

Hi Velocifyer,

...

browsh-bin now installs a sketchy NPM package despite it previusly not needing NPM. See <https://aur.archlinux.org/cgit/aur.git/commit/? h=browsh-bin> Thanks for the report! I confirm that the commit was malicious. It has been reverted and the user suspended.

Regards Claudia

You guys/gals are doing a great job, but I suspect we will have to go do some type of "confirmed identity policy" for all AUR accounts. The days of giving the benefit of the doubt, and account with commit privileges, to every anonymous/randomized e-mail are unfortunately over. I don't know what form this ID validation can take, but the proliferation of supply-chain attacks and AUR package poisonings necessitates something. At minimum, unless the to-be maintainer is willing to provide their full and verifiable name and location on the account, that should be segregated for further review. Currently AUR is simply too easy for any malicious actor to adopt a package an push poisoned dependencies as part of the PKGBUILD. You all know far better than I was is doable in this process, so I'll leave it in your safe hands, but did feel this is worth a comment and further discussion. This is why we just can't have nice things anymore. The internet was such a welcoming place in the early '90s :( -- David C. Rankin, J.D.,P.E.

On 5/27/26 6:38 PM, Aaron Liu wrote:

I don't see why requiring names would stop it. We'd end up with way less actual names (in fact mine isn't my actual) and all of the uploader accounts I see have a name in the username you can actually search up.

Plus, age verification is incredibly unpopular here and all the arguments against it apply.

If a package is orphaned, it probably isn't used.

Thanks Aaron, Yes, you are certainly right that a full-name alone isn't any type silver-bullet that will suddenly stop malicious attempts to take over AUR accounts, but by the same token, doing nothing doesn't seem like an answer either. I don't like these topics any more than the normal person, but I do follow supply-chain and repository attacks and the uptick in frequency across the board for all sites is alarming. The larger point is that as it currently exists, AUR is a wide-open repository for any individual to use in a malicious way. I think it is worth discussing what options are available to mitigate the risk that poses to Arch/AUR users. With the uptick of malicious activity seen just in the past few days, it may be a good time to think through what, if anything, can be done to harden AUR. I wish I had the answer, and if I did I'd waive my magic wand and ensure AUR stayed safe, trusted and secure henceforth. Unfortunately, the real-world doesn't work that way. I don't know what options/tools are available to the Arch Dev/Sec folks, that's why I have to leave it up to those smarter than I there. What I want to avoid, if possible, is some larger event that Claudia can't fix with speedy account deletion and a force push that does real damage to AUR users and its reputation in the process. Good discussion by all, and if something comes out of it that helps tighten and secure AUR in some way, we are all the better for it. -- David C. Rankin, J.D.,P.E.

On 5/28/26 2:32 AM, kyuunex@protonmail.ch wrote:

I'm against giving up my name and stuff too just to maintain aur packages, and if I'm forced to, I'm just disown or not update anything I maintain.

In past, I have adopted some packages I saw were orphaned and I use myself, not because I wanted to maintain them, but I wanted to prevent someone else from taking them over to spread malware. How did I find out they were orphaned? My AUR helper listed them as orphaned.

So here are my solutions

1. Improve moderation tools If subreddits can moderate better, and delete posts in under a minute, we can too. Improve UI, make it easy to spot suspicious changes, etc. I really don't wanna be specific, as I am not a reddit mod, but having a global moderation queue where accounts registered for a long time can flag something, could be a good start.

2. Have AUR helpers actually cooperate What I mean by this is, have them print a red warning that a maintainer has changed or if a package was recently adopted. Also have them print out a red warning if a user tries to update a package that was previously spreading malware, like "This package was previously taken over. If you installed that version, secure your machine". Have this be the default. Noone is gonna dig through aur helper man pages to find if this exists. This ofc would require some improvements with Aurweb RPC interface, but so be it.

I think a reputation system for PKGBUILDs would be highly effective. Currently only known-bad findings are reported, but known-good findings are not recorded anywhere. You could define a set of individuals you consider trustworthy and capable reviewers, then only accept PKGBUILDs onto your system that have positive reviews from N of those people. This kind of system already exists in the Rust ecosystem: https://github.com/crev-dev/cargo-crev There's also a toy project that parses the install hook into an AST and flags things you should probably look into, but it's fairly noisy because it flags every unrecognized command as suspicious: https://github.com/kpcyrd/smelly-hooks It would've flagged and pointed out the npm install in browsh-bin, yet you should probably not rely on this for security since "we didn't forget any shell scripting edge-case" is likely not something you want to gamble your computer integrity on. cheers, kpcyrd

Hello, what about using a Web of Trust (PGP keys) like mechanic ? Yes, malicious users will still get accounts this way, but my hope/thought is that the malicious accounts form group clusters in the trust graph, so that once 1 malicious user gets detected, many more can be easily detected purged together. With time it might be even be possible to have some warning alogrithm if multiple accounts that only lately gained trust immedeately vouch for many other new accounts. I know there's always the question how people that don't know anyone well can gain trust. In my idea I'd also vouch for someone who made multiple constructive comments on an AUR pkg of mine in a timespan of more than a year. Regards, Oskar Am Donnerstag, 28. Mai 2026 02:03:44 CEST schrieb David C Rankin:

On 5/27/26 6:38 PM, Aaron Liu wrote:

...

I don't see why requiring names would stop it. We'd end up with way less actual names (in fact mine isn't my actual) and all of the uploader accounts I see have a name in the username you can actually search up.

Plus, age verification is incredibly unpopular here and all the arguments against it apply.

If a package is orphaned, it probably isn't used.

Thanks Aaron,

Yes, you are certainly right that a full-name alone isn't any type silver-bullet that will suddenly stop malicious attempts to take over AUR accounts, but by the same token, doing nothing doesn't seem like an answer either.

I know I haven't been active on this mailing list, but I've been an Arch user for more than 10 years now, and I wanted to share my perspective on this. Identity and age verification in an IT context do nothing but harm, both to the community and the people in it, there are many, many examples and studies readily available that explain why. The gist of it is that, especially for an international community like Arch, nothing can ensure beyond a doubt that a malicious actor's identity is actually real. This entirely defeats the purpose of verification. Instead, it only puts honest people who don't "game" the system at an increased risk of identity theft and discrimination. Furthermore, doing something just for the sake of doing something is the worst possible incident response. If the action taken doesn't actually fix the root issue, doing it is worse than doing nothing; it creates friction at best and destroys trust in the system at worst. I agree that the status quo is insufficient and that something HAS to be done, but hastily put together solutions are not going to improve the situation. Unfortunately, I don't have any solution to suggest that might improve things right now, I only know that those won't. Fanfurlio -- Ignorance is a curable illness; all that is needed is the will to learn. - Please don't print this e-mail if you don't need to! On Thursday 28 May 2026, 01:38:32 (+02:00), Aaron Liu wrote:

I don't see why requiring names would stop it. We'd end up with way less actual names (in fact mine isn't my actual) and all of the uploader accounts I see have a name in the username you can actually search up.

Plus, age verification is incredibly unpopular here and all the arguments against it apply.

If a package is orphaned, it probably isn't used.

-- Cheers, Aᴀʀᴏɴ

Hi all, I am against identity verification, this exposes honest users to identity theft when/if the AUR is compromised, allows for easier censorship of packages that are legal but targeted by groups (yt-dlp vs RIAA). It also doesn't solve the problem of compromised AUR accounts pushing malicious updates. (Especially as most payloads target ssh keys and worm capabilities) I think efforts to solve supply chain attacks we should focus around hardening popular package owners such as mandatory 2FA for popular users (like Python PIP ecosystem did) and automated scanning solutions that detect issues (aws canarytoken triggered from a ci/cd leaked .env?) Moderation queues and mapping tools techniques and procedures can help detect and prevent waves. 1 day old registered users auto adopting orphaned packages should not have been an attack vector. User education about packages published from a new author or signed by a new GPG key should have additional alerting in AUR helpers. Would love to see some of our discussed plans and solutions become AUR gitlab issues for us to focus development effort. There is maybe also the potential for applying for grants or engaging in a sponsor to offer dedicated dependency firewall security services for the AUR (socket.dev?) Regards,

Even if it is not an issue of compromised accounts, wouldn’t 2FA help to reduce the number of new accounts created by bad actors? This would at least slow whatever automated workflow they have that goes from account creation to them injecting the malicious scripts. 2FA also doesn't feel as invasive as identity verification. On Thu, May 28, 2026 at 06:24 Pierre Chapuis <arch@catwell.info> wrote:

Hello list.

I didn't see what happened in this case exactly but in many cases this happened after a maintainer change, not because of compromission of the existing maintainer's account, so 2FA wouldn't solve it.

I think one of the most effective solutions would be requiring invites like e.g. lobste.rs does (https://lobste.rs/about#invitations).

Requiring reviews by "high reputation" maintainers after an adoption for highly-used packages could also help. The various UIs (AUR web and helpers) could also surface this to the user (warn when a new version is by a different maintainer for instance.

Finally, automated scans can always help I guess, but malicious people will often find ways to work around them.

Best.

-- Pierre Chapuis

Hello, Am 28.05.26 um 04:18 schrieb aur@nullvoid.me:

I am against identity verification, this exposes honest users to identity theft when/if the AUR is compromised, allows for easier censorship of packages that are legal but targeted by groups (yt-dlp vs RIAA). As others have noted, that is a horrible idea and defeats the great achievements in anonymity and freedom (including freedom from surveillance and government overreach) of the internet. Moderation queues and mapping tools techniques and procedures can help detect and prevent waves. 1 day old registered users auto adopting orphaned packages should not have been an attack vector.

I agree that accounts should have a cooldown period, and there are probably some signup limits that can be put in place. A proof-of-work scheme that requires more computing power than the current signup pseudo-captcha sounds useful (there are existing open-source and privacy-respecting implementations of this, but I don’t remember their names and don’t have time to look them up right now). Am 28.05.26 um 09:55 schrieb Pierre Chapuis:

I think one of the most effective solutions would be requiring invites like e.g. lobste.rs does (https://lobste.rs/about#invitations).

This would prevent isolated but still good-faith contributors from publishing on the AUR. For social networks like lobste.rs and many Fediverse instances, invites are a great approach, since people want to talk to their friends/acquaintances. The AUR is not a social network except in the broadest possible sense. While some people might start using Arch and publish to the AUR because someone recommended it to them, others may not, and that doesn’t automatically make them less qualified, that just makes them less part of a social circle where Arch is already widespread.

Requiring reviews by "high reputation" maintainers after an adoption for highly-used packages could also help. The various UIs (AUR web and helpers) could also surface this to the user (warn when a new version is by a different maintainer for instance.

This sounds like one of the best possible solutions. New packages don’t really matter, since nobody uses them, and people are more likely to check the PKGBUILD for packages they are newly installing anyways. Typosquatting is a related issue, but I don’t know if that has affected the AUR so far, and it also doesn’t affect updates that go through an AUR helper. I don’t claim to know what the workload on AUR maintainers is, but if possible, they should handle this. Otherwise, it would be good to have a more automatic feature that allows users to flag lesser-used packages with maintainer changes, which otherwise do not automatically require review. After all, there has to be some cutoff for package popularity below which no automatic review is invoked (to not overload the maintainers). Automatic review seems to be pretty much pointless. It can be as inocuous as a maliciously-crafted tarball that is pulled from almost the same upstream location as before. There’s a reason that malware scanners are not perfect. ~ kleines Filmröllchen

First - Thank you to all package maintainers and administrators. You're the magic behind all this. I'd also agree that identity verification doesn't provide much value, and likely presents more concerns. To Oskar's point below, we are not alone with this challenge, and it appears we can leverage others that have implemented processes to create "trusted users." - account cool down periods for new accounts is probably good. - identification or responsibility for who "vouched" for a user is probably good. - identifying suspicious behavior such as claiming an unusual number of orphaned packages is probably good. Changes discussed as needed to be able to address these issues are likely significant and foundational to how the AUR works. Monitoring to identify unusual/suspicious activity and link it through the current system may be a valid approach to help mitigate the risk. Controls to adding new maintainers or trusted users are also likely needed to reduce the cycle of malicious activity. Assuming it's frequent enough to warrant the energy. --Announcements on the AUR and this distribution list along with "validate what you're installing" have mostly been adequate for me as a user. If this discussion warrants further coordination and organization, what are the next steps or correct forum to manage feedback and ideas? Thanks, Confusedwiseman On Thursday, May 28th, 2026 at 12:03 PM, Oskar Roesler <oskar@oscloud.info> wrote:

On Donnerstag, 28. Mai 2026 14:00:10 Mitteleuropäische Sommerzeit, kleines Filmröllchen wrote:

...

I agree that accounts should have a cooldown period, and there are probably some signup limits that can be put in place. A proof-of-work scheme that requires more computing power than the current signup pseudo-captcha sounds useful (there are existing open-source and privacy-respecting implementations of this, but I don’t remember their names and don’t have time to look them up right now).

PoW only makes sense against fully-automated, highly scaled attacks. The current AUR malware attacks aren't like this, they are puposefully targetted. PoW would only heat up the Earth for nothing, bc doing this challenge a couple of times a week won't be a problem for attackers.

...

Am 28.05.26 um 09:55 schrieb Pierre Chapuis:

...

I think one of the most effective solutions would be requiring invites like e.g. lobste.rs does (https://lobste.rs/about#invitations).

This would prevent isolated but still good-faith contributors from publishing on the AUR. For social networks like lobste.rs and many Fediverse instances, invites are a great approach, since people want to talk to their friends/acquaintances. The AUR is not a social network except in the broadest possible sense. While some people might start using Arch and publish to the AUR because someone recommended it to them, others may not, and that doesn’t automatically make them less qualified, that just makes them less part of a social circle where Arch is already widespread.

I don't think this is as much of a problem & somewhat a necessary evil. When you take this concept further like with the Web of Trust alike concept proposal I showed in a previous email, it's more about malicious actors inviting/vouching/proofing each other, therefore forming clusters in the user graph that can be checked much more easily. Patterns of malicious actors should even be algorithmically detectable in the long-term. In the AUR, new comments would still be allowed for any user, which makes this very distinct from lobste.rs. And as pointed out previously, vouching for someone I don't know IRL is still possible, when it's less about gatekeeping & more about tracking who vouched for whom.

Regards,

Oskar

That's a pretty bad take no offence Mark, yes this is the Arh user repository where the user can read the pkgbuild code but there shouldn't be malicious packages there in the first place which is why it should have some better rules and regulations to avoid this while still remaining open and not controlling in nature. corey On Fri, 29 May 2026, 2:10 pm Mark Hegreberg, <mark@archlinux.org> wrote:

The expectation of the AUR is that users vet upstream software, and read the PKGBUILD, right? If you do this, none of the malicious packages I've seen would have affected you. I worry building any kind of fomal vetting or reputation system for aur packages will look like a defacto endorsement of the packages themselves, which i don't think we're trying to do.

Correct me if I'm missing something, but I dont see the value in anything past letting your AUR helper show you diffs, which the ones I've used all do. Anything else we do raises the barrier for community AUR contributions, and won't provide meaningful warranty or security. Mark

Hey, I don't like the adoption queue idea. I wonder if it'd be a good idea to simply flag all addition of/changes to .install files (maybe by new accounts)? One possible concern with this approach is it might make malicious actors disguise their efforts a bit more, say adding malicious commands to the shell script shipped to /usr/bin instead of running the command immediately as a .install hook. -- Cheers, Aᴀʀᴏɴ

Aaron,

One possible concern with this approach is it might make malicious actors disguise their efforts a bit more, say adding malicious commands to the shell script shipped to /usr/bin instead of running the command immediately as a .install hook.

interesting. this could turn out to be an "arms race", with each side innovating, the other responding.