I think this is a great way of preventing this attack vector for packages.
My only worry is that With time, this could be defeated. Let's say you still temporarily adopt the package and then it's a good commit. Then let's say maybe a month or a week from that point that you want to make this package malicious, you go to the staff and ask to fully maintain it. Yes, I know that this is social engineering, and there's nothing that could really prevent it. However, this kind of system could be bypassed via this kind of way. But I do believe that this is a great way of doing this. Or its at least A better solution than right now. Please note that a PGP key may be assigned to my email. If this key does not match between my emails it is a fake email and should be disregarded. Sent with proton mail. On Wednesday, June 17th, 2026 at 2:33 AM, Andreas Reichel <[email protected]> wrote: > 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 >
publickey - [email protected] - 0x55011640.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
