AI hype. Don't bother
Welcome to the Strip Mining Era of OSS Security
71–80 of 94 posts
Re: Welcome to the Strip Mining Era of OSS Security
#72Earlier quoted context omitted.
Curl had many old protocols and code from the 1990s that no one used. Besides, Mythos was claimed to be better than existing tools. In most open source projects, Mythos or similar tools have found nothing. The AI people only contact the projects where they find something, because it would be bad for marketing otherwise.
This is now the open source problem. And why my personal opus of work has been removed from online repositories. Who gave them "the right to scan"? You did by hosting your open source in public. But scanning a public service prior to AI was still covered by "Unauthorized System Access". But what if they are wrong, and given the self-serving nature of these scans, now your repo is just OJ Simpson? And your software is…
The open source problem argues for a modification of licenses to exclude certain uncompensated use in training commercial LLMs (which may arguably already be a violation).
With careful prompting, LLMs will give up some of their sources and methods. Claude describes the legally and ethically suspect methods Anthropic used acquiring training materials for its models.
The IP law and courts are starting to catch up (re: Anthropic settlement September 2025), but licensing language and enforcement has not.
Re: Welcome to the Strip Mining Era of OSS Security
#73Earlier quoted context omitted.
To address this framing directly: "a bug exists" is a different truth/state of the world than "the bug is known to exist", and that's also very different from "this bug exists and an exploit is readily available". So the transmission of information about the bugs does change the state of the world, and requires action.
There are actually three states: - A bug exists and nobody knows - A bug exists and some people know - A bug exists and everyone knows As an outside observer, there is no way for you to determine if a bug is in state one or two, you only know once it's in the third state. Which is the entire problem here. Having the bug be known to everyone is a vastly improved state over being known to a few. Yes, the bug being comp…
That's not the whole picture though. Bugs exist anyway. The only practical concern is, which are practically most likely going to be used among all these bugs that yes exist and included in production.
Re: Welcome to the Strip Mining Era of OSS Security
#74Earlier quoted context omitted.
If your assertion of falsehood were true, the current top story on HN wouldn't be Turso shutting down their bug bounty due to overwhelming slop.
This is not good reasoning. You're offloading your thinking to "Turso" for some reason. You're also assuming that they haven't made the alternative judgement that instead of triaging the haystack of slop that they get in order to potentially pay out to someone, they should instead be spending that cash and effort on tokens to find bugs in their own codebase.
You should read the mentioned article. They have hired some of the people they paid out to, and some of those people were LLM-assisted.
The claim I'm rebutting is "in the past few months nearly every LLM generated report is real." If that were true, there would be no need to close the bounty. The bounty is to address approaches that they themselves may not have considered, so would still hold value if the claim held true, as outside individuals may still hold unique LLM-assisted approaches and perspectives.
Re: Welcome to the Strip Mining Era of OSS Security
#75Whenever one of these vulnerability apocalypse posts comes along I cannot help but think of the Litany of Gendlin: What is true is already so. Owning up to it doesn't make it worse. Not being open about it doesn't make it go away. And because it's true, it is what is there to be interacted with. Anything untrue isn't there to be lived. People can stand what is true, for they are already enduring it. I cannot wrap my…
> I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
I don't think anyone is saying that here.
I think the net result is "wow, we're going to end up a lot more secure in several months, but things are going to feel sucky because stuff just got A) way easier for the average bad guy, and B) way busier on the fixing side."
I think it's likely we end up with an equilibrium with a lower rate of bug discovery than we're used to, but we need to experience an above average rate for a long while first...
Re: Welcome to the Strip Mining Era of OSS Security
#76Earlier quoted context omitted.
There are actually three states: - A bug exists and nobody knows - A bug exists and some people know - A bug exists and everyone knows As an outside observer, there is no way for you to determine if a bug is in state one or two, you only know once it's in the third state. Which is the entire problem here. Having the bug be known to everyone is a vastly improved state over being known to a few. Yes, the bug being comp…
That's not the whole picture though. Bugs exist anyway. The only practical concern is, which are practically most likely going to be used among all these bugs that yes exist and included in production.
You've described states one and two as outlined above.
Whether a bug is exploitable is an entirely separate category of unknowable, because seemingly-innocuous bugs quite often have very deep and very subtle implications that when combined with another innocuous bug, result in an RCE or PE.
Therefore, it's sensible to treat all bugs as potential threat vectors unless and until proven otherwise. Which brings us full circle: state 3, all bugs being public, is probably the safest thing because nobody can know if a bug is in state 1 or 2.
Re: Welcome to the Strip Mining Era of OSS Security
#77Clearly for commercial oriented opensource software, security through obscurity is one way to keep the pace in the short term. Not an option for proper open source software. Will this be the case that people who use open source software that is easily detectable will also start to shy away from using them for the fear of zero-days? One of the benefits of Open source has been that there are more eye balls on the sourc…
Lets be honest, LLM with fuzzers are going to pound any llvm generated binary right in the hubris. Won't matter if is closed source, signed, and or obfuscated. =3
Don't think you even need to qualify that with "llvm generated."
Re: Welcome to the Strip Mining Era of OSS Security
#78This is something I struggle with as someone building a tool for debugging and security. I have dog-fooded it heavily on my own projects, client projects and friends projects. It finds things that are really quite clever and not obvious. It really helps me. But when I try to do the obvious thing for sales of using an OSS project to get hype, show off etc. I find that it becomes really hard to really know that I am he…
So you slop-coded a tool, you're slop-generating reports, you know it has hallucinations ("false positives").. and you're complaining it's too much work to even verify the output? And you're surprised OSS projects are pivoting towards "open source does not mean open contributions"?
> And you're surprised OSS projects are pivoting towards "open source does not mean open contributions"?
How do you get that from:
> the risk is that people who don't understand the projects just point scanners at OSS blindly and ruin the good work maintainers are doing... and it's so easy to kid yourself into thinking any bug report is helpful.
Re: Welcome to the Strip Mining Era of OSS Security
#79Earlier quoted context omitted.
Lets be honest, LLM with fuzzers are going to pound any llvm generated binary right in the hubris. Won't matter if is closed source, signed, and or obfuscated. =3
Don't think you even need to qualify that with "llvm generated."
Nondeterministic compiled code-motion in llvm means a workaround can't reliably be patched given version permuted bug emergence.
Fun times =3
Re: Welcome to the Strip Mining Era of OSS Security
#80Earlier quoted context omitted.
Don't think you even need to qualify that with "llvm generated."
Nondeterministic compiled code-motion in llvm means a workaround can't reliably be patched given version permuted bug emergence. Fun times =3
It's certainly possible to write optimizations that generate nondeterministic llvm outputs, but the docs explain conditions when that can happen, and warn against it.