I've been helping a bit with OWASP documentation lately and there's been a surge of Indian students eagerly opening nonsensical issues and PRs and all of the communication and code is clearly 100% LLMs. They'll even talk back and forth with each other. It's a huge headache for the maintainers.
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.
It sounds funny, but it's not. I once issued a bug to them that didn't have enough information about how to reproduce... and I was lambasted on Reddit and eventually just deleted my account there it was so terrifying. Some dev teams do not mess around. In fact I've shied off most social media since and no longer issue bug reports to any company, I was scarred deep over the treatment.
Projects are not going to be so open open their development process if they have to keep wading through emoji-filled and erroneous PRs. The Bazaar doesn't work so well if nobody can get around the piles of manure that are being delivered
Seems like a lot of the problems had by the low friction of first eternal september and now LLM genrated reports and contributions, could be resolved by restoring friction. First time reporters/contributers could be required to send their report or PR by paper mail. Strict requirements for the sender: all text printed on postcards (no letter opening) as QR or other data codes according to a standard formatting. Anything even slightly off goes straight to the trash, high signal/interest contributors can still get their foot in the door.
Ah, brings back memories when TPB did something similar to when MPAA and their "associates" emailed them. I think this is probably the best page where one could still see them: https://web.archive.org/web/20111223101839/http://thepirateb...
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.
I am friends with a solo maintainer of a major open source project.
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.
Context: [1, 2]
> 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...
I think this is probably less effective than if there was some sort of "credit" or reputational score for reporting that seems like something GitHub would have the information to implement.
I wonder if there is a way to blanket prevent these types of problems.
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.
While I understand the frustration with bad reports, this is how you get more of them (from the spiteful) and fewer good reports from the people you just threatened.
Every site and every service is going to be swamped with AI-generated slop and will have to deal with it by banning it, and then detecting and deleting it.
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.
- I notice a lot of stuff in github issues all the time
- 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
There's going to be avalanches of code everywhere. You can no longer expect some human to know what some code does or maintain it.
The policy link[0] page still has a link to the bug bounty program[1] which still discuss monetary compensation.
Somehow, I knew this would be curl before finishing reading the headline. Good on them!
Can anyone tell me in 2025 how much big tech made in revenue from AI..
Links to all those crap reports: https://gist.github.com/bagder/07f7581f6e3d78ef37dfbfc81fd1d...
(from https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s...)
I love curl.
Having an overly long captcha for bug bounties / reports may be the one place where it serves a purpose
they're suffering from this big time: https://www.youtube.com/watch?v=6n2eDcRjSsk&t=2453s
Seems fair.
This note isn't going to stop even 1% of the jackasses who would have submitted AI slop.
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.
This is great actually. I can feel the sentiment of the slop they've had to deal with.
Fair play to them.
I think this is the perfect application of a micro payment service. Each PR must be signed with a nominal amount of money, say $0.15 give or take. You send in a commit, with no expectation to get it back.
> ridicule you in public
love this. more projects should use this kind of language. cut the bullshit
Fair enough.
It's been an issue for a while and it's even bigger now in the age of AI. Lots of people use security as a way to "have their moment" and don't really care about adding value.
But scaring people off from security reports also isn't a great idea either.
Dog whistle to AI. Love it.
Creating crap vuln reports or PRs on popular OSS projects has been an issue long before LLMs. Remember Hacktoberfest?
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.
I'll leave this chart to speak for itself https://ourworldindata.org/grapher/number-of-internet-users?...
I like the idea of refundable submission fee for bug bounties. No refunds for slop and poorly researched submissions.
Why is cURL specifically receiving so many slop contributions? Or is this a recent phenomenon for every open-source project, and cURL are the ones most spoken of? First time commenting on HN!
One way this can backfire: if you have no reputation and are nobody, and get banned and publically ridiculed, this is now a badge of honor you can take to wealthy and deluded people convinced of the AI future, to say 'look, I have been shot at! I'm a true believer!'
And then maybe they will give you money.
lol, fair and square
[dead]
[dead]
[dead]
Why do I always hear the cURL guy's opinions on this and that?
> We will ban you and ridicule you in public if you waste our time on crap
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)
Long time ago Sourceforge and then GitHub promoted into the current default the model of open source distribution which is not sustainable and I doubt it is something that the founding fathers of Free Software/Open Source had in mind. Open source licenses are about freedom of using and modifying software. The movement grew out of frustration that commercial software cannot be freely improved and fixed by the user to better fit the user's needs. To create Free software, you ship sources together with your binaries and one of the OSI-approved licenses, that is all. The currently default model of having an open issue tracker, accepting third party pull requests, doing code reviews, providing support by email or chat, timely security patches etc, has nothing to do with open source and is not sustainable. This is OK if it is done for a hobby project as long as the author is having fun doing this work, but as soon as the software is used for commercial, production critical systems, the default expectation that authors will be promptly responding to new GitHub issues, bug reports and provide patches for free is insane. This is software support, it is a job, it should be paid.