Live data from Hacker News

We stopped AI bot spam in our GitHub repo using Git's –author flag

archestra.ai

171–180 of 254 posts

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#171
post #164

Earlier quoted context omitted.

> What is bot logic exactly? Ill thought out logic like your own. I think you are likely a bot at this point. It's not likely, because that's not something that people are likely to do. Only a bot like yourself with a poor model of the world will do this type of thing. It will be amusing to see the AI bots trying to run the scam you are describing and then nobody will contribute to the fake projects... except other f…

Dude, you're claiming that there's no likelihood of people getting swindled out of their money by handing it over to strangers. So your reaction is to play the bot card? We're done. You're clearly not arguing in good faith here.

> people getting swindled out of their money by handing it over to strangers.

I think that OP is trying to say is that there is very little reason for a human to go through the trouble of contributing to a "plausible looking fake repo".

To get to the point that a repo starts to attract interest from other contributors, that project needs to have actual utility.

Who in their right mind would jump into opening a PR from projects they never used? And if the project does get used to the point that it attracts people interested in contribute to improve it, wouldn't it mean that we've achieved https://xkcd.com/810 ?

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#173

[flagged]

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?

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#174

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.

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…

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.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#175
post #55

> 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.

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.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#176

'I will take "problems that could be easily be solved by implementing a Pfand system" for $200, Alex.' Seriously. Just ask for a US$10 deposit for the each PR. If the PR is accepted (not even merged, just accepted as "this is a good effort"), give it back. Hell, give double the amount for good effort and you got yourself a cheap way to attract good contributors. Best case, bots will balk at the payment. Worst case, t…

What? No. A PR is me giving my time to the project. I don't get anything out of it except the warm feeling of having helped out. If I have to pay money to submit a PR then I'm going to play video games instead.

> A PR is me giving my time to the project

Unfortunately, the issue is that time is not enough of a filter anymore. The time from machines is basically worthless compared to yours, so you need to give something else, and that something else needs to be something that shows you have actual skin in the game.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#177

[flagged]

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.

Closing a PR or issue still makes it discoverable in PR/issue search results, as opposed to deleting an issue.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#178
post #23

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…

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

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)

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#179
post #158

Earlier quoted context omitted.

It's cheating if the projects using it are cryptocurrency related :) A generic python library used by generic people who have no interest in this field is something else.

Coinbase reports more than 100+ user accounts worldwide. Kraken has ~10M. Also, we are talking about people who are tech-savvy enough to be interested in participating in a FOSS project. Opening an account at an exchange is not rocket science.

No, getting the money out of an exchange if you are in a country USA doesn't like is rocket science. Which was the whole point of using crypto rather than money.

Re: We stopped AI bot spam in our GitHub repo using Git's –author flag

#180
> If the email matches their GitHub account, GitHub links the commit to their profile and grants them contributor status.

When the article mentioned email matching, I was concerned that it would break down when a contributor's email address changes. (I have contributed to more than a few projects over the years, using email addresses that no longer exist.)

However, it looks like they're not using the email address recorded in the author's original git commit, but instead a GitHub-generated address whose unique parts are the GitHub user ID and username. That should survive authors changing their email addresses. It would still break down if a contributor loses access to their account and has to create a new one, but that's probably less common.

Post reply on HN