Re: Ideas for moderating malicious AUR packages
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. (this is my first time mailing this list, if I am being stupid please tell me nicely)
On Sunday, May 31st, 2026 at 03:14, Carson Coder <carson@carsoncoder.com> 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.
(this is my first time mailing this list, if I am being stupid please tell me nicely)
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 is also my first message to the list, so please be gentle.) Best regards, Jack-Benny Persson
I think it's not a good idea. It makes the attack surface very predictable, and 10 trivial and believable commits are not that hard to do On 5/31/26 11:41, Jack-Benny Persson wrote:
On Sunday, May 31st, 2026 at 03:14, Carson Coder <carson@carsoncoder.com> 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.
(this is my first time mailing this list, if I am being stupid please tell me nicely)
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 is also my first message to the list, so please be gentle.)
Best regards, Jack-Benny Persson
It's going to heavily bottleneck them though. 10 believable commits aren't hard, but imagine doing that at scale. 10 is easy, 100 is hard, 1000 is nearly impossible. If we only had one account posting malware at any given time I would consider it a victory. -- Borna Punda -------- Original Message -------- From: "Damian Höster" <damian.hoester@posteo.de> Sent: 31 May 2026 12:04:29 GMT+02:00 To: aur-general@lists.archlinux.org Subject: Re: Ideas for moderating malicious AUR packages I think it's not a good idea. It makes the attack surface very predictable, and 10 trivial and believable commits are not that hard to do On 5/31/26 11:41, Jack-Benny Persson wrote:
On Sunday, May 31st, 2026 at 03:14, Carson Coder <carson@carsoncoder.com> 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.
(this is my first time mailing this list, if I am being stupid please tell me nicely)
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 is also my first message to the list, so please be gentle.)
Best regards, Jack-Benny Persson
My mail server was misconfigured so I missed a couple of emails so I am just going to reply to this one. Well thats why I said at the end of my email "maybe have some sort of system so someone can't just make 10 commits to change the version of a package". It is easy to make 10 trivial commits but if we some system where even 100 trivial commits wouldn't make you "trusted" ("trusted" as in, getting your commits not flagged) but 5 well made packages does. And yes, you can automate making commits to change a word or updating packages, but if we have a system like what I just described, that wouldn't get you "trusted". And yes, this would do a sort of denial-of-service attack but we could have bigger commits have more priority over smaller commits so new packages would be reviewed before a commit to update a package is reviewed. Malicious actors are going to try to upload malware but this makes that harder, its better than nothing. On 5/31/26 06:04, Damian Höster wrote:
I think it's not a good idea. It makes the attack surface very predictable, and 10 trivial and believable commits are not that hard to do
On 5/31/26 11:41, Jack-Benny Persson wrote:
On Sunday, May 31st, 2026 at 03:14, Carson Coder <carson@carsoncoder.com> 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.
(this is my first time mailing this list, if I am being stupid please tell me nicely)
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 is also my first message to the list, so please be gentle.)
Best regards, Jack-Benny Persson
My mail server was misconfigured so I missed a couple of emails so I am just going to reply to this one.
Well thats why I said at the end of my email "maybe have some sort of system so someone can't just make 10 commits to change the version of a package". It is easy to make 10 trivial commits but if we some system where even 100 trivial commits wouldn't make you "trusted" ("trusted" as in, getting your commits not flagged) but 5 well made packages does.
And yes, you can automate making commits to change a word or updating packages, but if we have a system like what I just described, that wouldn't get you "trusted". And yes, this would do a sort of denial-of-service attack but we could have bigger commits have more priority over smaller commits so new packages would be reviewed before a commit to update a package is reviewed.
Malicious actors are going to try to upload malware but this makes that harder, its better than nothing.
I agree that It should not be based on the amount of commits but change volume. I suggest comparing code simply using matching, i.e how much of your code has changed from the previous build. I know that it says nothing on its own, but it can be combined with the 10 commit idea to see if they push a large change without declaring such or just wait out the 10 commit quota before pushing a malicious change. Specifics can be figured out later such as comments being ignored in said parsing. On Sun, 31 May 2026 at 09:03, Carson Coder <carson@carsoncoder.com> wrote:
My mail server was misconfigured so I missed a couple of emails so I am just going to reply to this one.
Well thats why I said at the end of my email "maybe have some sort of system so someone can't just make 10 commits to change the version of a package". It is easy to make 10 trivial commits but if we some system where even 100 trivial commits wouldn't make you "trusted" ("trusted" as in, getting your commits not flagged) but 5 well made packages does.
And yes, you can automate making commits to change a word or updating packages, but if we have a system like what I just described, that wouldn't get you "trusted". And yes, this would do a sort of denial-of-service attack but we could have bigger commits have more priority over smaller commits so new packages would be reviewed before a commit to update a package is reviewed.
Malicious actors are going to try to upload malware but this makes that harder, its better than nothing.
On 5/31/26 06:04, Damian Höster wrote:
I think it's not a good idea. It makes the attack surface very predictable, and 10 trivial and believable commits are not that hard to do
On 5/31/26 11:41, Jack-Benny Persson wrote:
On Sunday, May 31st, 2026 at 03:14, Carson Coder <carson@carsoncoder.com> 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.
(this is my first time mailing this list, if I am being stupid please tell me nicely)
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 is also my first message to the list, so please be gentle.)
Best regards, Jack-Benny Persson
Committing too often is also uncommon. I think a moderator could reflag someone who makes ten trivial commits very quickly. -- Cheers, Aᴀʀᴏɴ
On 2026-05-31 at 09:41:14 +0000, Jack-Benny Persson <jack-benny@cyberinfo.se> wrote:
On Sunday, May 31st, 2026 at 03:14, Carson Coder <carson@carsoncoder.com> 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.
Sent with Proton Mail secure email. On Sunday, May 31st, 2026 at 10:32 AM, 2QdxY4RzWzUUiLuE@potatochowder.com <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
On 2026-05-31 at 09:41:14 +0000, Jack-Benny Persson <jack-benny@cyberinfo.se> wrote:
On Sunday, May 31st, 2026 at 03:14, Carson Coder <carson@carsoncoder.com> 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.
Bad defense. Attackers will do anything to mask themselves under civilians, even if it means helping in the short term. -------- Original Message -------- On Sunday, 05/31/26 at 05:35 Carson Coder <carson@carsoncoder.com> 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. (this is my first time mailing this list, if I am being stupid please tell me nicely)
Bad defense. Attackers will do anything to mask themselves under civilians, even if it means helping in the short term.
The point isn't to completely stop them (that's impossible), but to make it too expensive to do at scale which would hopefully stop the bulk of the attacks. -- Borna Punda
participants (9)
-
2QdxY4RzWzUUiLuE＠potatochowder.com
-
Aaron Liu
-
Borna Punda
-
Carson Coder
-
Damian Höster
-
isameme
-
Jack-Benny Persson
-
nikooneshot.blurb049＠silomails.com
-
Noah Peeling