I suggested following what Ghostty does where everything starts as discussions - only maintainers create issues, and PRs can only come from issues. It seems like this would deter these sorts of lazy efforts.

I'm not sure it helped in the end, afaik they did it since like 2003 until some years after the raid, but it still seemed like they didn't get the message and kept trying anyways, which from their perspective makes sense but still.

He repeatedly complains that at the beginning of some semester, he sees a huge spike of false/unproveable security weakness reports / GutHub issues in the project. He thinks that there is a Chinese university which encourages their students to find and report software vulns as part of their coursework. They don’t seem to verify what they describe is an actual security vuln or that the issue exists in his GitHub repo. He is very diligent and patient and tries to verify the issue is not reproducible, but this costs him valuable time and very scarce attention.

He also struggles because the upstream branch has diverged from what the major Linux distribution systems have forked/pulled. Sometimes the security vulns are the Linux distro package default configurations of his app, not the upstream default configurations.

And also, I’m part of the Kryptos K4 SubReddit. In the past ~6 months, the majority of posts saying “I SOLVED IT!!!1!” Are LLM copypasta (using LLM to try to solve it soup-to-nuts, not to do research, ideate, etc). It got so bad that the SubReddit will ban users on first LLM slop post.

I worry that the fears teachers had of students using AI to submit homework has bled over into all aspects of work.

> Open source code library cURL is removing the possibility to earn money by reporting bugs, hoping that this will reduce the volume of AI slop reports.

> cURL has been flooded with AI-generated error reports. Now one of the incentives to create them will go away.

[1] https://news.ycombinator.com/item?id=46701733

[2] https://etn.se/index.php/nyheter/72808-curl-removes-bug-boun...

If the discussion leads to the insight, that this is worth a feature, the maintainer will implement it.

I think the same goes for PRs. If you think you have made something cool, then discuss it and offer your implementation and the maintainer makes it fit with you to integrate.

On the other side, if you want a feature it just doesnt have, simply forking it and updating from the source-repo is fair enough.

Possible solutions I can think of:

- Require an account with a paid service. Fix = require money - Require an account verified with real ID/passport etc. Fix = link to real person - Automated reply system to "waste tokens" if it is an AI that is responding. Fix is increased cost of spammer. - Have some kind of "vetting system" where you get on an allowed list to report these types of things. Seems not good to me, but perhaps there is something in it.

I wonder how much open source code is lost because maintainers must deal with this type of thing versus the "good" that AI can bring in productivity.

- For example, there is this +1 comment pasted like 500 times that I have seen a lot over issues

- Cant we have a github regex bot of sorts ^(\W+)?\+(\W+)?1(\W+)?$ that removes all such comments? or let the author of the repo control what kind of regex based stuff to remove?

- I know regex kind of sounds old fashioned in the age of LLMs but it is kinda simple to manage and doesnt require crazy infra to run

[0] https://curl.se/dev/vuln-disclosure.html

[1] https://curl.se/docs/bugbounty.html

This was entirely predictable. When you give everyone the ability to be good at something with no effort, everyone is going to do it (and think they are the first).

My partner recently bought a book from Amazon, and when it arrived, I looked at the cover, flicked through it, and said it was AI slop. She complained to Amazon, and they just refunded her, no questions asked, and the book went in the fire.

(from https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s...)

Fair play to them.

But scaring people off from security reports also isn't a great idea either.

Students would often abuse it since there’s no adult in the room to teach them how to behave. I guess this is one hard way to f around and find out. But this is by no means condoning this sort of behavior.

Point is, LLMs made the situation more dire: it’s cheap to generate code, whereas reviewing still scales sublinearly. The only way to prevent this is by being rude to people who are rude to you.

love this. more projects should use this kind of language. cut the bullshit

There are much better ways to communicate the intended message. This comes off as childish to me and makes me think that I'd rather not contribute to the project.

And then maybe they will give you money.

If shame worked, then slop reports would've stopped being made already. Public ridicule only creates a toxic environment where good faith actors are caught up in unnecessary drama because a maintainer felt their time was being wasted. Ban them, close your bug bounty program, whatever, but don't start attacking people when you feel slighted because that never ends well for anyone (including curl maintainers)

"As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities"

Why have a code of conduct while being hostile to contributors?

I think they should handle this differently.