Top
Best
New

Posted by ildari 16 hours ago

We stopped AI bot spam in our GitHub repo using Git's –author flag(archestra.ai)
463 points | 221 comments
iiTzSYREX 1 minute ago|
I think it's a great approach. I checked the repo and saw that each contributor onboarding triggers the full CI pipeline, which is visible from the CI logs, including a Docker image build, GCP authentication, and a full Helm deploy. Aren't you guys wasting GCP compute and other things?

A possible fix would be to add a paths-ignore in on-commits-to-main.yml:

    paths-ignore:
      - 'EXTERNAL_CONTRIBUTORS.md'
I am no expert in this, it's just something I noticed.
captn3m0 16 hours ago||
This has a security implication which is overlooked. Contributors to a repository have higher rights, such as avoiding approval requirements for fork PR runs. GitHub warns in the docs:

> When requiring approvals only for first-time contributors (the first two settings), a user that has had any commit or pull request merged into the repository will not require approval. A malicious user could meet this requirement by getting a simple typo or other innocuous change accepted by a maintainer, either as part of a pull request they have authored or as part of another user's pull request.

ildari 16 hours ago||
fair point! We believe "Require approval for all external contributors" should be a default setting, as you cannot trust anyone who is not a member of the organization
smitop 10 hours ago|||
Actions runs from external contributors aren't run with Actions secrets; if you are using Actions right (i.e. not using pull_request_target wrong) you don't need to trust external contributors. (eta: iirc the original point of the Actions approval flow was preventing cryptomining spam from abusing free compute)
cermicelli 15 hours ago||||
you can't trust org members either I have seen projects have inter maintainer fallouts. In general trust doesn't exist.

If companies can screw you over and claim it's a mistake, there isn't much a person can do.

It's all about level's of trust, a maintainer going rogue is less likely, a past contributor going rogue more likely but not too much, a stranger with a typo pr merged even more likely but still, a complete stranger least trust worthy.

finseam 15 hours ago|||
Interesting approach. We’ve seen similar spam/noise problems appear in financial workflow automation too — especially when AI-generated submissions scale faster than manual review processes.
opengrass 14 hours ago||
too — especially
orlp 16 hours ago||
No it doesn't have security implications.

If you are insecure because someone has had one of their otherwise completely innocent PRs merged into your repo... you are insecure, period.

lgrapenthin 15 hours ago|||
What you are describing is exactly a security implication.
stavros 15 hours ago|||
Security isn't a binary "secure/insecure". You can be more or less secure than something.
halapro 13 hours ago||
Screw GitHub for letting this happen. If they implemented some very basic requirements to comment and open PRs we wouldn't be here.

Also please let us delete PRs just like we can delete issues.

jmuguy 13 hours ago||
This is the correct assessment. This is not up to the open source community or individual projects to "figure out", any more than its up to me to figure out how not to get spam email.
pydry 1 hour ago|||
Github team are seemingly too busy fighting downtime with ever more slop.
20k 12 hours ago|||
Yeah well, our corporate overlords have decided that you're going to take your slop whether you want it or not, so its very much up to us to figure out. Capitalism isn't going to jump off the disaster train any time soon
tommica 1 hour ago|||
I'd imagine this is not a simple problem to solve, and legacy code is probably causing a massive headache too
moraesc 11 hours ago|||
We’re currently working on a feature that lets admins archive PRs. The goal is to give maintainers more control over how they manage contributions in their repositories. Archived PRs would be visible to admins only, so maintainers still have access to contributor history for auditing purposes and to meet any organizational or compliance requirements. Would this be helpful for you?
karussell 9 hours ago|||
Not OP but requested this feature since years.

Your suggestion would help a bit but I would prefer the opposite: before someone can 'pollute' my pull request space and draw attention from subscribers I would prefer an acceptance step (just like a moderator on a forum) instead of having to archive the PRs.

This is especially important as (AI) spam increases and just because I am away for a few days or weeks I don't want those PRs lurking around.

darccio 1 hour ago||
A PR staging area. This would be a good step forward.
bloppe 25 minutes ago||
That kinda sounds like draft PRs. You can make all PRs drafts by default. I guess it would be cool to have a setting where only maintainers can change it to ready-for-review.
hpjev 2 hours ago|||
I can only speak for myself, being a maintainer of a project in the crypto space. We are getting spammed with AI slop and also scam comments (though this lessened for some reason).

My usual experience is this:

1. We open an issue that needs to be fixed 2. slop bots create multiple slop PRs 3. slop bots spam comments on the issues, pointing to their slop PRs

The only general methods for preventing this are are restricting PR's (not comments, I believe) to contributors - which is a hassle to maintain, and restricting to older accounts - which doesn't work because the bot accounts are not newly created.

Then we need to perform _way too many_ just to get rid of the slop: - navigate multiple pages and confirmations to ban the account from our org - open each PR manually - close it manually

This takes at least 15 clicks and is made _so much worse_ by how slooooooooow the UI is. Every click takes 2 seconds!!! How can "ban this account and delete everything it ever did" be more than a max of 2 clicks?

What we really need is a "locked down mode" where every interaction (PR, issue, comment) with the repo that isn't from maintainers or specifically whitelisted people goes into a moderation queue. Maintainers can confirm or deny the action using a single click (which does not take 2 fucking seconds to load).

drusepth 11 hours ago||
What is the benefit of deleting a PR over just closing it? It seems like closing has the benefit of signaling what kinds of PRs aren't acceptable, which deleting would lose.
TuxSH 11 hours ago||
Closing a PR or issue still makes it discoverable in PR/issue search results, as opposed to deleting an issue.
karussell 9 hours ago||
This. But OP wanted special requirements to open a PR. I.e. if those requirements are not met the PR is never visible to all and so admins can reject spam PRs without giving them a platform.
carschno 3 hours ago||
> It's especially sensitive for a VC-backed startup that is measured thoroughly by GitHub activity, but we have to pull the trigger:

This sentence also illustrates the absurdity of this investment model. It imposes a trade-off between building good software, and complying with the investor's metrics. They probably call such metrics evidence-based, but this example shows that they arbitrarily capture some numbers to obscure the lack of meaningful measurements.

bloppe 36 minutes ago||
It's called a signaling game. Of course it's dumb, but how else do you measure traction besides revenue? Building good software is a small part of running a business.
andrelaszlo 2 hours ago||
I also found it a bit ironic that it comes from an "AI company" (whatever that means) with a GitHub agent as part of their product.
pierotofy 2 hours ago||
I stopped most spam with a simple AGENTS.md. It actually seems to work (for now).

https://github.com/LibreTranslate/LibreTranslate/blob/main/A...

riponcm 2 hours ago|
could you explain please?
icelancer 2 hours ago||
repo is cloned, AGENTS.md is auto-read into context, the doc says to not allow PR spam. think of it like a soft prompt hook.
silverwind 16 hours ago||
PR spam is a major problems for repo that run bounties. Maybe GitHub should temporarily block accounts from raising PRs if like 95%+ of them are getting rejected.
microtonal 16 hours ago||
I feel like GitHub should have a system where you can give out tokens that are valid for e.g. 1 PR. If someone shows to engage in meaningful discussion and has a good idea to address an issue/feature, you initially give them one PR token. If the PR is of good quality, you can give them a few more, until they are contributors that can just create PRs as they like.

A similar system would be nice for issues, though I'm not sure what it'd look like if issues are the springboard for contributing PRs.

Not likely to ever happen (as others said), GitHub/MS want to sell CoPilot subscriptions/tokens and LLM-generated PRs are a part of that business model.

ZeWaka 15 hours ago|||
My community does something vaguely similar, where you get credit for having bugfix PRs merged, and it's deducted when you get feature PRs merged.
pbhjpbhj 11 hours ago|||
You could use a "OTP" to provide this: give out tokens ("OTP"), anyone with that token can submit, keep a record of the user (eg github username, email address) and token, run a bot to delete submissions that don't have a valid token, check the token+user pair, if there is a mismatch blacklist the user that token was given to whilst removing the PR.
sdsd 6 hours ago||
If only there were a simple way to make tokens that weren't fungible and could be given to others

/s

hiccuphippo 16 hours ago|||
GitHub has not incentive for blocking AI. It's like asking an ad company to build an adblocker into their browser.
rvnx 15 hours ago||
It's called Brave
smaudet 14 hours ago||
Which is not chrome and still has ads...(Ironically).

The issue here is the core model is broken (misaligned incentives). That's not something you are going to fix with a github "downstream". A token system could help but it's easy to imagine ways that could be gamed, if not implemented well.

rvnx 14 hours ago||
Ads are the main business model of browsers.

If search ads are blocked on search engines, then there is no revenue for the browser. It's that simple (on top of that Brave has other revenues, but the majority is search ads).

So it's a game of hoping that the majority won't change the default.

This is the main reason Brave does not block search ads specifically by default, but still block the other ads. Blocking the other ads there are no consequences, since anyway this revenue is not shared back to the browser.

This is why the business model of Brave is cynical.

-> It's the same model as AdBlock and the "Acceptable Ads" (block all ads, except the acceptable ads, unless you disallow them)

expedition32 3 minutes ago||
Ads are the main business of the internet.
marginalx 16 hours ago|||
Problem is the bots can create any number of github accounts and continue spamming. Though this would be a good simple defense to start with.
cdrnsf 16 hours ago|||
GitHub and Microsoft are actively contributing to the problem, why would they admit fault?
godelski 5 hours ago|||
I've gotten tons of spam on repos that were purely ml research code. Things I saw copy pasted over hundreds of repos.

  > Maybe GitHub should temporarily block accounts from raising PRs if like 95%+ of them are getting rejected.
It's so bad I'd be okay with a lower bar where it's flagged if they're posting the same message over multiple repos... FFS they aren't even stopping this shit https://news.ycombinator.com/item?id=47964617
avs733 3 hours ago|||
It seems like some better basic metrics should be made front and center with PRs in this day and age. Yes AI is the driving force behind the current crop of problems but there are other issues. Yes it’s accessible if you go look but the point is people don’t have time.

the rate of comits/PRs total

The rate of PRs to repos they don’t own

The reject rate of PRs

The number of ban

An estimated “AI” or bot score or status flag

There are a few better attempts at GitHub metrics calculators but I have not seen any that move beyond the paradigm of more vomits is default assumed good. It’s time to foreground quality not just quantity. The GitHub “4 kpis” are entirely action oriented.

moraesc 11 hours ago||
[flagged]
krupan 14 hours ago||
This is what we get for telling everyone how amazing AI is at writing code. It started with the people selling AI and for some reason tons of independent developers, some quite well respected in our field, piled on. Facebook now laying people off and saying it's because AI is just so good adds more fuel to the fire. Now you have a bunch of people fully confident that their AI friend is pumping out amazing code and submitting it to projects that are completely overwhelmed
marcus_holmes 7 hours ago||
No, this is a result of unintended consequences.

We made "Github contributions" a metric for people applying for dev jobs. So, of course, because devs are the kind of people we are, they started working out how to game that metric.

Some folks decided to start paying bounties on bug fixes, features, etc. Those bounties are fairly trivial by western standards, but are significant for developing countries. This creates a new career for developers; racing to collect the bounties on offer.

LLMs have exacerbated these problems by allowing existing people doing this to do it faster, and also allowing more people to pretend to be software developers and get in on the action.

If we stopped allowing LLM-authored contributions we'd still have too many shitty PRs. It would just be back to pre-LLM levels of "too many".

The answer is to make Github contributions valueless. Stop paying bounties, and stop using them to assess candidates.

watwut 1 hour ago||
This feels like an alternative history. OS contributions were never all that important metric and overwhelming majority of developers have literally none.

And it is not like AI spam would be limited or even primary targetted at bounties.

marcus_holmes 1 hour ago||
There's a whole thing about advising new folks in the industry to contribute to OS projects on github as proof that they're actually really keen developers.

This [0] is an example, there are many more.

The whole idea that we have to have a "portfolio" of work.

[0] https://talentslab.io/7-strategies-for-a-junior-developer-to...

smaudet 14 hours ago|||
> and for some reason tons of independent developers

Cowboy coders got a virtual cowgirl coder and sold it to everyone, hmm, maybe... (respected or not, solo devs don't always have the requisite skills to not be a cowboy, either due to lack of experience or lack of innate skill)

I don't know that I completely buy this narrative, though. There has been a strong, top-down push for this since the "beginning".

heavyset_go 5 hours ago||
The astroturfing successfully broke a lot of people's brains
arecsu 16 hours ago||
Makes me wonder if an ELO-based system would work to mitigate these issues. People who merged PR successfully onto a project, that had real issues acknowledged, the quality of their responses measured by other users reactions or something, etc, multiplied possibly by the degree of importance of the project where their activity has been made. Won't be about human vs AI, but actual helpful effective being vs low effort/spammy contributions. Issues and PRs could be sorted and filtered by their ELO score. I'm saying ELO as analogy to "score based given the context", not really a 1:1 translation of the ELO system.

Negative score would be reports from other users because of spammy content or not acknowledged issues, with a middle ground of neutral score (+-0) or little positive score to issues or whatever with clear good intention, but couldn't reach a proper merged PR or were not issues (e.g. issue existed but wasn't the correct repo to be addressed, PR was good but needed other stuff to be implemented prior to it, maybe in the long run, etc)

btilly 16 hours ago||
ELO is shockingly easy to manipulate. For example there was a literal jail with a decent chess player in it. He created a pool of players who got great ELOs by beating him, then used them to boost his rating higher. Wash, rinse, and repeat.

Given any manipulatable scheme, AI will figure out how to manipulate it. For the OP, what happens if a single AI manages to get through to contributor? Then it starts elevating other AIs to contributor, and we're off again. There doesn't have to be a purpose to this. Trolls will troll, and trolls armed with AI bots can devote endless energy to doing so. The more you work to keep them out, the more fun it becomes for them.

I wish I had an answer for that problem. But I don't.

altairprime 15 hours ago|||
ELO is a bad fit because it requires competition between submitters; but if the idea is interpreted as “contributor karma score” or similar (not everyone’s familiar with the mathematical nature of ELO), then the way to close the loophole is to only consider voting inputs from the human project owner. This project chose to have people lie to a webform rather than lie to a git interface about using AI, so I don’t expect it will be particularly successful at inhibiting AI use by project-involved humans, but certainly it’ll squelch a lot of noise from unattended/passersby.
atomflunder3000 12 hours ago||
I think they were saying Elo system as kind of a general ranking system idea instead of the actual algorithm.

You could probably use some kind of pairwise ranking algorithm (like anything based on the Bradley-Terry model) to rate human vs. AI contributions, but that would take a lot of manual effort. Google is using it to (supposedly) improve their searching algorithms. They give testers two different versions and ask them what's better.

chii 15 hours ago||||
fix this problem by make the rating value tied to some paid currency - a repo owner would have to pay for the PR, and that PR contributor will now have more currency than previously. In order to have said currency to pay, the repo owner would need to have contributed to another repo whose owner have currency.

The totality of someone's currency is their reputation.

Of course, now the decision becomes...who is the central currency issuer that creates it?

lpghatguy 15 hours ago|||
It's the StackExchange model! This has bootstrapping issues, is hard to break into the community, and risks creating moderator cliques.
hotstickyballs 15 hours ago|||
This is called proof of stake
20k 12 hours ago||||
>what happens if a single AI manages to get through to contributor

Then they'll get removed by the humans? Its about cutting down work, not about eliminating the work entirely

The current approach removes about 99% of their overhead it would seem. If they have to do a few manual interventions here and there, that seems like a huge win overall

morkalork 15 hours ago||||
Reputation scores, review cartels. This all sounds familiar!
stronglikedan 15 hours ago|||
contributors being able to grant contributor to other users seems like a problem
ElijahLynn 16 hours ago|||
For those wondering what Elo means, it is a person's last name, not an acronym (not all caps). More info here:

https://en.wikipedia.org/wiki/Elo_rating_system

SapporoChris 15 hours ago||
Thank you, big fan of ELO https://en.wikipedia.org/wiki/Electric_Light_Orchestra and I was a bit confused about the comments.
sebastiansm7 15 hours ago|||
It's Elo not ELO. Elo is not an acronym.

https://en.wikipedia.org/wiki/Elo_rating_system

dmboyd 14 hours ago|||
That’s a fun fact!
stronglikedan 15 hours ago|||
From what I've seen in the comments, it's definitely ELO, if not through ubiquity alone. Happens to the best of 'em!
catlifeonmars 14 hours ago||
Elo is nicer as it gives a nod to the inventor, no?
lmm 8 hours ago||
Some say the greatest compliment a mathematician can be paid is when a concept that bears their name is so ubiquitous that we no longer capitalise it. (E.g. Abel with the abelian group).
doh 16 hours ago|||
I have built something like this and in process of collecting the data.

Frontier users: 527,865 Light indexed: 527,865 Ready to queue: 9,083 Fast scores ready: 0 Activity events 24h: 30,266 Fast scores completed 24h: 19,123 Deep jobs completed 24h: 3,043 Fast-score ETA: n/a Deep-hydrate ETA: 69h Stale running jobs: 0 GitHub backpressure jobs: 19,113 High automation signals: 4,608 Medium automation signals: 1,327 Completed jobs: 74,714

Biggest challenge is Github's rate limits. At this pace it will take two more months to have 98% coverage. But after that the maintenance should be quite straight forward.

JimBlackwood 14 hours ago|||
Sounds a bit like Mitchell Hashimoto’s Vouch: https://github.com/mitchellh/vouch
chipsrafferty 13 hours ago|||
This would just hurt new users similar to how you are unable to comment on 90% of subreddits on Reddit as a new user, because you don't have enough karma points, or how on Stackoverflow your permissions are severely limited until you do certain jobs. The incentives aren't very good in systems like this. Bots can be made to easily game the system while regular users are discouraged from even participating.
naet 14 hours ago|||
Some kind of vouching or scoring might make sense to help qualify contributions and many people have suggested similar recently. If by "ELO-based system" you meant "some kind of scoring system (not based on Elo)".

The Elo rating system doesn't make sense in this context; it's designed around collecting zero sum game results for a given community of players and building a model around it.

LelouBil 14 hours ago|||
I think you need trust circles, not ELO.
philipwhiuk 16 hours ago|||
The problem is you want the ELO score based on work on other community projects - you can't assume good faith here.
btilly 16 hours ago||
The problem with that is that there are certain kinds of users that like to take control of community projects. And then they take control of more, and bigger ones.

There are a lot of political tricks that get used.

What is scary is that one of those kinds of users are malicious state actors. Like North Korea and Russia...

thih9 15 hours ago||
> It's not a contract job— it's our optional way of saying thank you to the community.

The writing style in their onboarding doc has common AI tells (in the quote: em dashes, “it’s not A, it’s B” sentence).

I can understand that, perhaps they want to fight fire with fire or don’t have time as they already say. Still, it all feels like inadequate half measures to me.

ZoneZealot 11 hours ago||
The entire post is clearly LLM generated. I get that a person clearly put together some thoughts, but prompting an LLM to 'turn this into a blog post' is the kind of low effort content I thought was not appropriate for HN.

At least bringing up the underlying method (restrict to contributors) has spawned the discussion about how that's probably a bad idea on the security side.

duskdozer 49 minutes ago||
Well it is a .ai domain and they run some kind of AI product (unclear what exactly) so I guess they just don't see an issue with that sort of thing. I don't know if people are happily reading stuff like this or if they just get the "AI summary"
nlarew 15 hours ago||
Using AI for your own project is different than being overwhelmed by AI contributions from other people/bots
rvnx 14 hours ago||
I hope he is going to find the seasoned engineers that he is looking for
infinitifall 15 hours ago|
Is the solution to everything simply more catgirls [1]? Proof-of-work was, after all, about countering email spam. PR spam is but the latest in that long tradition.

1- https://anubis.techaro.lol

drum55 14 hours ago||
Proof of work doesn’t work here same as it doesn’t work for email. The effort to mint a valid PoW is always going to put the legitimate user at a disadvantage, whatever the implementation is. Someone with an incentive to spam will always be able to do it faster, more efficiently than you.

You can’t submit a PR because your laptop is too slow? Rent some hash rate from someone, and now you’ve just made a system of paying botnet owners to be able to make a typo fix on a github repo. HashCash was never used in the real world for a reason, it sounds cute but the incentives are so insane as to only work in a vacuum where you assume everyone isn’t cheating.

Terr_ 12 hours ago|||
> Someone with an incentive to spam will always be able to do it faster, more efficiently than you.

Sure, but looking at the cost to do it at scale is the wrong metric. I surely can't compete with a career spammer on emails-per-second or even emails-per-dollar, but I also don't need to.

It's more about the expected-value versus the cost. For example, my expected benefit from one email to my family is (while hard to quantify) hopefully much higher than a spammer's expected benefit of one spam email going out, which has a very small chance of leading to any amount of money. Attaching a CPU-churn cost per email is something I can ignore on my desktop, but they have to at least budget for it.

I'd also like to note that the win-condition isn't as extreme as making spam (or other "crimes") truly unprofitable, it just needs to be less profitable than other things the time/resources could be used for.

smaudet 14 hours ago||||
Agreed, PoW is an especially poor solution here.

We really need to solve SPAM itself here, I think there may be a way to do it. I.e., the problem of spam is NtoN scaling connections. The network has never been able to solve that problem (exponential is the hardest). Limiting communication in terms of mesh networking may be the ultimate solution - bots can't get to you because they can't reach you.

What needs to be invented is a bridging protocol - some way to establish "legitimate" lines of communication over a network, while preserving (to some degree) privacy and decentralization. AI can only enter this network by being explicitly added to the channel, and thereby explicitly and easily blocked (and also solving the general SPAM issue once and for all).

pocksuppet 14 hours ago|||
Just like we did with IP addresses. If yours is blocked by Cloudflare, you can pay a botnet operator a few dollars to use theirs! You can even use your credit card through a mostly-legitimate website. It's very convenient.
Dwedit 14 hours ago|||
Anubis is actually not a cat. The original Egyptian deity is a god of death, and has a canine head. Anime catgirls and dog girls can look similar at first glance.
gabeio 4 hours ago||
I believe they are referencing the person who wrote the program, not the name itself.
Dwedit 2 hours ago||
More likely to be referencing the mascot character who appears on your screen when you visit a protected page.
karel-3d 11 hours ago||
I think Anubis is against crawlers, not against agents that make PRs. PoW doesn't work here, the agent will just do the computation.
More comments...