I would like to bring to your attention that pkgctl already exists and covers some of the functionality you mention <https://man.archlinux.org/man/pkgctl.1>
---- As far as your idea specifically, let's look at the password storage algorithm. A single round of SHA256, even if salted, isn't considered a secure way to store a password nowadays, because one of the properties of SHA hashes is that they are fast to compute. If you really wanted to do this you would want to apply like 500 000 rounds of SHA256. A secure hash for password storage would be Argon2id, see the link below for more detailed recommendations: <https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html> ---- Adding more passwords into this flow is not a great idea IMO, SSH public key authentication doesn't require AUR to store anything beyond the public key, why add another password into the CLI flow when your SSH key should be already at least encrypted or ideally stored in a protected way (FIDO2 security keys can be used for that relatively easily nowadays). AURweb has a way for you to add ssh keys, I think the UX of that is simple enough already and that way you only maintain a password for the webUI. I'm fairly sure you can do most operations you would need to implement the other mentioned functionalities with the SSH interface, IIRC you can just SSH into AUR and get access to some management functionality. ---- As far as the idea of staging changes… In most cases the package owner is the only person that can push to a package, so this wouldn't change anything. In this incident what was abused was mostly the orphan package adoption system, where packages that didn't have an owner could be adopted by anyone, and here were adopted by malicious actors. Also, the possibility to forcefully disown packages if the owner doesn't deny the disown request within a specified timeframe, which is an issue for some niche packages that hardly ever get updates and thus the maintainer may not be very active. ---- In summary it's nice to see that you're excited about helping with this, I would recommend to familiarize yourself deeper with what happened first though. There is a thread on fedi which is a good starting point in researching, although it focuses more on the malware rather than the structural issues that allowed it to happen: <https://gaysex.cloud/notes/andaxow7itfn05x9> I'm not sure if there is too much public discussion as I would imagine AUR maintainers want to keep some of the mitigations private to stay ahead of the attackers, but the lack of oversight over orphan package adoption seemed to be a common thread. Another place of concern I have is that when a package is dropped from the official repos, AUR helpers will often decide to pull updates from the AUR instead of notifying the user about the change. Of course this is a failure of AUR helpers, but I think some sort of protection for package names of things that used to exist in the official repositories should be adopted. Perhaps one is already being devised, but I'm not privy to this. On 26 June 2026 12:35:27 CEST, Cavidan Rzayev <[email protected]> wrote: >im re-posting this as when i sent my last email i forgot to subscribe to >aur-dev > >first of all thank you if you read this and i would like to forward my >proposal to you regarding the AUR malware problem and how we can look at >fixing it with an official CLI developer tool and new staging workflows to >make the life of devs easier without needing any effort from the tus: > >i think the arch team can make an official developer CLI tool called >aurctl. right now making and updating packages is a bit of a mess because >people have to use a web portal for ssh keys, manually build .SRCINFO, and >push blindly to master. > >with aurctl it can look like this: >1. aurctl auth login -> uploads your ssh key to your profile via api >2. aurctl init <package> -> auto-generates a clean PKGBUILD template and >metadata files >3. aurctl push --commit="msg" -> locally runs validation checks on the >PKGBUILD syntax, auto-builds .SRCINFO, and signs commits seamlessly > >to fix the security without overloading the volunteer trusted users, the >code changes could just go to the package owners instead of the tus. if a >co-maintainer wants to change code, their push can go to a staging branch >instead of master, and the main owner can look at the diff and approve it, >which takes zero time from the arch staff. and if a package is orphaned and >someone tries to adopt it, the majority of the maintainers of that package >would have to agree and the changes could also be approved by the owner so >adopting and immediately changing would need the owners to approve more >than once and not need any effort from the tus. > >and also to show the exact workings of how the aurctl authentication loop >functions locally and on the server, here is the basic step by step logic >for how it works: > >1. When a user runs 'aurctl auth login' the first time: >[Client Side] >user_secret = "input_password" >unique_salt = generate_random_string() >secure_hash = sha256(user_secret + unique_salt) >-> Send secure_hash and unique_salt to the server > >[Server Side Database] >Save user profile: { username: "name", salt: unique_salt, hash: secure_hash >} >(The cleartext password is never sent or saved anywhere) > >2. When a user tries to run 'aurctl push' to update a package: >[Client Side] >-> Request package push for username >-> Server sends back that user's unique_salt from the database > >[Client Side calculation] >input_secret = get_password_from_terminal() >current_hash = sha256(input_secret + unique_salt) >-> Send current_hash to the server along with the code payload > >[Server Side validation] >if (current_hash == database.secure_hash) { > allow_git_merge_to_staging_branch() >} else { > reject_unauthorized_push() >} > >this completely cuts out the risk of database leaks or credential sniffing >on public networks, and the server only has to execute a single basic >string comparison which requires almost zero CPU or memory footprint. >and again, thank you very much for taking my ideas into consideration and >making this wonderful distro
