>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 <[email protected]> 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
> >> <[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.
> >>>
> >>> (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
>
