Sent with Proton Mail secure email. On Sunday, May 31st, 2026 at 10:32 AM, [email protected] <[email protected]> wrote: > On 2026-05-31 at 09:41:14 +0000, > Jack-Benny Persson <[email protected]> wrote: > > > On Sunday, May 31st, 2026 at 03:14, Carson Coder <[email protected]> > > wrote: > > > > Hi, I had an idea. What if we flagged the first 10 commits from a > > > new user for manual review? That way a malicious actor would have to > > > make at least 10 good commits, before making a malicious commit. The > > > main downside I can think about is that this might add a lot more > > > work for the moderators but also it would make making malicious > > > packages harder / take longer. Even then, if someone does make 10 > > > good commits and then makes a malicious commit, they would have at > > > least contributed 10 good commits. Maybe we could even make the > > > number of commits vary from user to user (maybe have some sort of > > > system so someone can't just make 10 commits to change the version > > > of a package) so that its harder to know how many good commits need > > > to be made. > > > Hi, I think this is a an excellent idea. Like you said, even if a user > > makes a malicious commit after those first 10 commits, at least they > > contributed with those commits. And generally speaking, the harder it > > is to make a malicious commit, fewer bad actors will have the patience > > to keep at it. There will still be bad actors with lots of time and > > patience, but the bulk of them might not. > > This seems pretty easy to automate and to work around. With a little > work and some tools that already exist, I could build a new tool that > generates a dozen changes from "happy" to "glad" at irregular intervals > over the course of hours or days or weeks. Now in addition to staking > my claim for being released from moderation, I have executed a miniature > denial-of-service attack against the AUR. This also puts the moderators > into the difficult position of having to review and judge (in the worst > possible sense of the word "judge") every commit by every newcomer. (I > could even contribute my tool to the AUR, and make a defensible claim > that it was approved by the AUR moderators.) > > All of these ideas are trying to quantify the notion of trust, which > (as has been pointed out) at some level is at odds with welcoming new > contributors. > > In some sense, the mere fact that this discussion is taking place (and > consuming any resources at all) is a victory for a certain set of bad > actors. Yes, standing back and watching seems like a less and less > viable path forward. But also yes, many bureacracies hierarchies and > dictatorships and other highly centralized and restrictive organizations > started wuth good intentions at the grass roots level and worked their > way up from there. > > No, I don't perform a critical code review on every PKGBUILD I get from > the AUR, but I do give the changes a once over, and I do dig a little > when I changes beyond just updating checksums. > Hello I'm also new to the mailing list. I do propose that we should do something like this, but ten commits is not enough. How about let's make those commits only be available on bigger projects as well? Sure, yes, this would probably cause an issue, but those are still A, good commits, B, They can't just make some random thing on the AUR. It has to be something that's public Something that people would notice. I do know that this would probably be an issue for someone like me who doesn't like talking much. If I did anything wrong, please email me.
publickey - [email protected] - 0x55011640.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
