Lukas, thank you for these thoughts, all valuable input. I absolutely love AUR since it provides me with convenient packages for outdated GTK2 packages which are still need for rubbish corporate VPN application (NetSkope!). So I would like to aopologise for playing the advocatus diaboli in this discussion:
1) lets assume I am a state sanctioned criminal syndicate with at least 20k USD deep pockets 2) lets assume further I am aiming for operating a resilient network for operating and controlling malware 3) lets assume that I am able to deploy one or two Epyc servers with a 70bn plus LLM On Tue, 2026-06-16 at 19:57 +0100, Lukas Grumlik wrote: > > Instead of keeping the doors completely open, a safer approach would > be to change how orphaned packages are handled. > > The moment a package loses its maintainer, it could go into a locked, > read-only state. People can still download it and use it as it is, > but the instant adoption button gets disabled. It stays locked until > an actual user notices it is broken or outdated and submits a proper > request to take it over, explaining why it needs updating. This alone > would stop automated bots, as a script cannot fake a genuine build > error or give a proper reason to adopt. This discourages casual good-will supporters who were working on something completely else, noticed a short-fall in between, wanted to fix it for their own purpose in good faith and share for the greater benefit. Which is 99% of the open source developers, let alone non native English speakers. It will not stop me, because my LLM Agent has all the time it needs and will write better explanations anyway. > Once a request is accepted, the new maintainer could be put on a > temporary status. Instead of their first update going live > immediately to everyone, it could go into a staging area where the > system automatically checks the changes in the build file. And who shall do that? Who sponsors this work and effort? > If the update tries to point the source URL to a completely > different, dodgy domain, or adds sketchy download scripts, the system > blocks it before it hits the public index. If it looks clean, it gets > pushed out normally. Very much agreed but again you are fighting maybe 100 evil people like me with deep pockets -- so a powerful LLM instance was they only way to implement that w/o tearing down the ARCH/AUR maintainers (who do all of that in their spare time in good will!). Running capable LLMs is expensive and w/o a corporate sponsor (Valve, please come to the rescue!) I don't see how to implement. > This puts a solid barrier in front of malicious actors without > creating a mountain of extra paperwork for the team. It uses the > community to flag what actually needs fixing, ensuring energy is only > spent on software people are actively using. Sorry, I don't see any barrier, I see only effort for the AUR team so far -- and more obstacles for the majority of quick casual fixes. > > Would love to know if something like this could be considered to help > secure the repository moving forward. The discussion is very helpful and necessary. And I would like to apologise again for putting the sparing up. All the best and cheers Andreas
