On 8/8/26 10:36 PM, noexec wrote:
I was arguing that the AUR shutting down without any real plan forward was irresponsible from a security updates perspective, and the fact that last time it shut down registrations for 2 weeks just to add that simple vibe-coded commit shows a lack of real changes or a plan forward for the AUR; I think "lazy" was an understatement since you then released an announcement acting like the AUR was now safer.
Not exposing ideas / plans publicly doesn't mean we don't have one.Regardless, constructive criticism is okay of course. Baseless accusation of vibe-coding and uncalled judgment on the quality of improvements attempts made by volunteers (which do not owns you anything by the way) is not. Please read and comply with our Code Of Conduct [1]
[1] https://terms.archlinux.org/docs/code-of-conduct/
My proposal, which many people have already talked about primarily outside of the AUR mailing list, is a trusted user system. weighted factors of their maintaining history and integrating some level of trust system. While not perfect, it would help flag what needs review to the users; as you said, it's the "Arch User Repository."
Once again, we're not lacking ideas... Unless your willing to help implementing and participating to such a system, this doesn't bring much to the table.
This trusted system, captchas, and basic modern signup and sign-in features are not putting much weight on the nearly 60 volunteers and trusted users.
It's easy to ask for more and make assumption when you're not a part of it.First of all (as much as it might scared you regarding your made up expectations regarding the AUR security), be aware that there is far from 60 volunteers actively working on the AUR moderation.
Secondly, even in the eventuality if we were all actively moderating the AUR (still as volunteers and aside from our other duties within the Arch project), there is 117191 PKGBUILDs referenced on the platform at the moment and huge numbers of related requests to deal with daily. I can confidently tell you that we cannot handle more burden (as tiny as it might be) in the current state of things.
Lastly, you seem to underestimate the amount of work required to integrate such sign-up / signing / captcha / trusted system feature within the existing platform. Things like SSO support for instance is something that has been evaluated already, the integration as well as the migration of all the existing accounts within that new system is far from being trivial.
There's another issue with the current system and how packages are removed and banned when infected: there's no warning on the page that they were previously infected. The trusted user who revoked it might show as the last publisher temporarily until a new maintainer is found, but there's no indicator that it was infected. An open, viewable log of all changes to a package would fix this completely since all users can independently verify, and then it can be extended to AUR helpers to implement, which can pull the same info.
There's already open & public log of changes. The reason why you did not see the malicious commits anymore from there is because we purposely reset (--hard) them in order to prevent people from pulling them accidentally. I don't see the benefit of keeping knowingly malicious things around (which is just a risk for people to get infected accidentally / unexpectedly). As a reminder, AUR helpers are unsupported, so they are irrelevant here.
I mentioned you updating personal projects only due to you shutting down the AUR for everyone else, for much more security-needed packages than system tray applets.
As I showed in my previous answer, I haven't only used my staff privileges to bump personal packages but also to remove dangerous and broken stuff during the AUR maintenance. Regardless, I don't need your authorization nor I own you any explanation or justification for using my staff privileges.
-- Regards, Robin Candau / Antiz
OpenPGP_0xFDC3040B92ACA748.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
