You should consider reading the article, it might give you somz insight. (Support contracts. The answer is support contracts. Companies voluntarily pay money for curl to be maintained because they rely on curl.)
The incentive structure needs to change. Part of the researcher payout should probably stay locked until they actually help get the patch all the way into production. Right now the setup feels pretty unfair: one side gets to monetize automation, while the other side is left dealing with stress, incident response, and unpaid overtime.
Well the payout isn't even the problem. When these people/orgs find bugs in OSS, they usually disclose them regardless of reward*. Then they feel compelled to follow "responsible disclosure" and reveal the bugs publicly after X amount of time, regardless of the fact that they've thrown 35 bugs of varying severities over the fence at once.
*Technically I don't know for sure, maybe there are a bunch of people who aren't hackers that find bugs and sit on them waiting for a cash reward. I'd hope not.
This is probably a sign of things to come: devs from this point on are going to be too burnt out to care about reviewing, even worse with employed devs, because they have pressure to accept the 10k PRs/hour or lose their job.
You know the answer here is going to be "more AI" right?
Writing AI agents to assess incoming PRs for validity, rejecting any which bounce off the guardrails or duplicate another PR and then passing any which get through the funnel to a human for approval.
To an extent it's a storm that should blow over at some point because currently AI work is underpriced - AI companies are giving away resource in order to grab market share and raise investment. It's possible that AI work will eventually be actually cheaper than human work but right now I think that it's not really cheaper and is a false economy.
But then... why are they building so many new data centers?
If the price goes UP after it's no longer "experimental"/"finding its market"/etc -- won't quantity demanded go down?
Or is the hope that even as price goes UP, the demand curve also moves so people demand more even as prices go down? None of this makes a ton of sense to me.
It's like there's currently an assumption that the medium-term future will be (1) more AI than today and (2) more expensive AI than today which seems... unlikely...
I'd guess that they're using the investment to grab market share then work on drastically reducing the costs later. If costs are low enough then the equilibrium price will be reached as for every other service.
OTOH they are talking about moonshots like creating AGI which would probably make the whole question moot (hypothetically, I don't think it's likely to reach that level).
In this specific domain, LLMs do have massive advantages over human researchers trying to find exploits, hence the added pressure on maintainers who might be forced to use LLMs to make the fixes quickly enough - if they don't mind paying to do so. So it's a bit of a trap the AI corps have laid.
It might be the answer is to stop making all the vulns public.
The data centers are for hype-derived projections of usage. AI companies need to maintain the hype at all costs, or else they lose investor funding and implode. These companies are offering their services at an unprofitable rate, sustained by investor hype money, so they can corner the market and get a ton of users hooked on using their product. Once one of them crowds out the others and becomes dominant they'll jack up their prices and rake in the profits from the customers that can no longer function without AI.
That's the plan at least, though I don't think that's how it's going to play out. What's more likely is the bubble popping and a lot of these companies (or at least their AI divisions) will collapse. After that who knows.
It's already happening at my job. I asked for advice on reviewing the 10k+ line PRs, that can now be churned out every few days, in a reasonable amount of time. Unfortunately that was the answer - make ai review the pull request, ask it to highlight specific things and then human review those handful of things.
And I guess we find out the rest from production exploding later. I've invested a lot of time in reviewing my own ai assisted PRs because I care about what I'm putting out, and the ai usually makes a few small mistakes in very large changes. Caught one the first time that would have prevented us from serving any new customers if it went through. Caught one this week that was reading a feature flag in the wrong place so it would have turned the entire system off if this feature flag for 1 part of it was not set.
I think reading the code isn't enough. Even if the tools become mostly flawless, that 1 critical error per 10,000 lines changes is going to kill your business eventually. I think a business with a lot of ai written code is going to need a test environment that tests the entire system end to end every time there is a release. My business has talked about that before, but unfortunately the ai era arrived before we could set that up.
I'm sure the people that ran businesses on paper and pen, thought the same about trusting computer systems with their documents.
I hate it as much as the next person. But it is the next revolution. I've been using Claude/Codex to fully plan and integrate with then code reviews happening from both myself and AI, and honestly. It does a pretty good job.
This is web dev though. I think the one thing lost is my ease of integrating AI is not the same as a developer working on Unreal Engine 6 for example.
Or maybe writing bulletproof software is just really really hard. And finding ways to break it is not, relatively speaking. Hopefully it doesn't end up that way.
I mean it is legitimately harder when your project is written in C. Had curl been written in Go or Rust it would be less vulnerable but whether there is lack of flexibility or other problem in them that means nobody has been able or willing to port the likes of curl to them, i don't know.
Much of Rust's safety comes from well-thought-out libraries carefully encoding preconditions and postconditions in types, so that the compiler helps ensure programs using that library are doing so properly.
It's going to be just as hard to write the library itself, just with a different distribution of where you're spending most of the effort.
Had Curl been written in Go or Rust, only Go or Rust libraries would use it; it would be known only in those circles, not in the whole ecosystem/planet. C API remains the most important one. At least for now, but every new hardware gets assembly and C support, not Go or Rust support.
Rust has really solid interoperability with the C ABI through FFI. You can write a library in Rust, compile it into a shared object, and export standard C headers. To the end user and the operating system, it just looks like a normal C library, but under the hood you still get Rusts memory safety guarantees
rustls-ffi is a pretty clear example that this approach is completely viable in practice.
You can do the same in Go, compile to c-shared library, a c-static, export functions to C ABI. But, at that point, what is the point? Just use C where you need C.
Are you saying that you can compile a C compatible module from Rust or Golang code? Because you absolutely can. Curl has they hyper backend already although it's had some issues (I'm not following closely).
Memory safety is definitely the way forward and we don't need to rewrite curl (although some are trying e.g. https://github.com/jonwiggins/urlx) just the exposed parts where most of the exploits are found.
I'm not sure this is how it will go. AI tokens will get more and more expensive, I think there will be a divide where many folks carry on doing things the "old hard way" and make great software simply because it's economical.
At the moment most of this noise is being created by bots and resume factories attempting to build up someone's credentials to make them look like a great hire.
Once hiring moves away from, "How many open source projects do you contribute to?" and companies start cancelling their bug bounty programmes, this noise will go away.
LLMs crossed a boundary that is allowing them to be decent enough at finding bugs. Also I'd argue that the bot phase has passed: if I see someone with a lot of security bugs I'll go deep until subject, if I realized this was an AI slop spammer they'd get a strong no hire automatically. Also must bounty programs ended or added enough filters to avoid spamming strategies.
What I suspect we're seeing now is engineers, researchers and students using LLMs as tools and identifying new vulnerabilities that would have been hard for a human alone to see. See LLMs see code very differently to humans, they don't understand what the code really is, but they see the patterns in the text itself, they can identify problematic patterns that humans normally wouldn't look at (especially in good, readable code, in a twist): it's like those color blindness tests where you see a different number of you have a certain color blindness or none. You still need a human to comb through this patterns and decide what is real or not, and build a deeper report.
So right now we're seeing the rush, the code has accumulated insidious bugs in 30 years of work on it, and only now it's all being revealed at the same time. Going in further you'll catch these class of bugs as they appear, rather than letting them all pile together.
It's also that it's tedious work. It would be different if it could be a huge global hackathon funded by the AI companies, where you'd just throw the tools at the codebase. Let's all collectively stop working on anything else, and just up and fix the big open-source projects. Not possible at all, of course.
The AI companies could at least throw piles of money at curl, that would be the proper thing to do.
Oh the situation is messy and companies that depend on curl should throw money, because otherwise a bush hat hacker could rediscover on if these vulnerabilities using AI as well. It's a security liability not too. And yes this includes all AI companies.
But my point is that things will improve as we won't get a backlog of hidden bugs suddenly uncovered by AI for the first time, instead we'll catch these as they are introduced.
Bug bounty programs aren’t going anywhere, because for companies it’s still cheaper to pay a researcher $ 500 for an ai-discovered bug than to deal with the fallout of a real production breach
Not really, he's saying the load is coming from more and more high-quality bug analysis and reports. That's good, but his team and he are not being funded in the amount needed to properly address these issues. This isn't AI ruining things, this is companies who depend on curl the world over taking advantage and refusing to chip in the bare minimum to maintain the commons. I hate to say it, but this is in effect because of the MIT license. It provides no mechanism to fight freeloading in the least.
The "thousands of security bugs" are a 30-year cumulative count of issues found and fixed - not ignored - thanks to curl being one of the most scrutinized, fuzzed, and verified codebases on the planet. They’re receiving around one report per day, with almost all vulnerabilities rated LOW or MEDIUM severity, and the last HIGH was in 2023 (which you should have know, if you've read the article). Every bug reported means a bug fixed, and the flood of reports is a sign of relentless security work, not neglect. But sure, panic about the project that actively and transparently hunts down and patches its issues. The project multiple instance of which helped you post your "take" here.
If new bugs are being discovered every single day and have been for a while, that suggests the codebase is a complete mess. If you paved a road with a thousand broken stones, should you be commended that you fix one stone every day?
Your road analogy is nonsense. Software isn’t a static pile of stones - it’s a living system that evolves, faces new threats daily, and runs across countless platforms and protocols. The "endless bugs" are endless discoveries from relentless scrutiny and better tools, which is exactly what you want from security-conscious software. Most are low-severity, as pointed out before, all get fixed quickly. Again, you're criticizing the project for being thorough instead of the ones shipping unaudited code and hoping for the best.
And I find it wild your writing this about Curl of all things.
What software are you shipping that's forever free of bugs in a constantly changing context?
What you want from good software is an endless supply of security bugs that are discovered? I'd want good security by construction. How can you put your trust in software that constantly has new problems popping up?
Again, you're criticizing the project for being thorough instead of the ones shipping unaudited code and hoping for the best.
I'm sure this blog post is great but when you post something to reddit or anywhere really - people with absolutely no context will see it. I have no idea what something titled "The pressure" will be about and have no reason to click it. I assume it's not an essay about plumbing. The only other piece of context is the URL.. Daniel.haxx - okay, I've heard this name before - he write curl, right? If you provided a title or description briefly outlining what the essay is about many more people might click, just saying
I really appreciate that Daniel takes the time to write these great blog posts despite how overwhelmingly busy he is.
I feel like they're often a strong foreshadowing of my own experience (obviously to a lesser degree) in my own work and organization.
I have experienced many of the same things he has described in his blogs over the past year and gone through the same phases, including this one where as recently as today I was describing to some folks the experience of dealing with what now feels like an endless influx of content and code that is for all intents and purpose correct, but requires enormous effort and focus to validate that correctness, and it's starting to feel completely unsustainable to manage without burning out.
CommercialAttempt210@reddit
How does this guy make money from curl if it is open source?
sabzeta@reddit
https://curl.se/sponsors.html
Kwantuum@reddit
You should consider reading the article, it might give you somz insight. (Support contracts. The answer is support contracts. Companies voluntarily pay money for curl to be maintained because they rely on curl.)
CommercialAttempt210@reddit
I read it quickly but must have missed it.
Valuable_Leave_7314@reddit
The incentive structure needs to change. Part of the researcher payout should probably stay locked until they actually help get the patch all the way into production. Right now the setup feels pretty unfair: one side gets to monetize automation, while the other side is left dealing with stress, incident response, and unpaid overtime.
Norphesius@reddit
Well the payout isn't even the problem. When these people/orgs find bugs in OSS, they usually disclose them regardless of reward*. Then they feel compelled to follow "responsible disclosure" and reveal the bugs publicly after X amount of time, regardless of the fact that they've thrown 35 bugs of varying severities over the fence at once.
*Technically I don't know for sure, maybe there are a bunch of people who aren't hackers that find bugs and sit on them waiting for a cash reward. I'd hope not.
lelanthran@reddit
This is probably a sign of things to come: devs from this point on are going to be too burnt out to care about reviewing, even worse with employed devs, because they have pressure to accept the 10k PRs/hour or lose their job.
seamustheseagull@reddit
You know the answer here is going to be "more AI" right?
Writing AI agents to assess incoming PRs for validity, rejecting any which bounce off the guardrails or duplicate another PR and then passing any which get through the funnel to a human for approval.
imp0ppable@reddit
To an extent it's a storm that should blow over at some point because currently AI work is underpriced - AI companies are giving away resource in order to grab market share and raise investment. It's possible that AI work will eventually be actually cheaper than human work but right now I think that it's not really cheaper and is a false economy.
which1umean@reddit
As far as I understand, this is true :-)
But then... why are they building so many new data centers?
If the price goes UP after it's no longer "experimental"/"finding its market"/etc -- won't quantity demanded go down?
Or is the hope that even as price goes UP, the demand curve also moves so people demand more even as prices go down? None of this makes a ton of sense to me.
It's like there's currently an assumption that the medium-term future will be (1) more AI than today and (2) more expensive AI than today which seems... unlikely...
imp0ppable@reddit
I'd guess that they're using the investment to grab market share then work on drastically reducing the costs later. If costs are low enough then the equilibrium price will be reached as for every other service.
OTOH they are talking about moonshots like creating AGI which would probably make the whole question moot (hypothetically, I don't think it's likely to reach that level).
In this specific domain, LLMs do have massive advantages over human researchers trying to find exploits, hence the added pressure on maintainers who might be forced to use LLMs to make the fixes quickly enough - if they don't mind paying to do so. So it's a bit of a trap the AI corps have laid.
It might be the answer is to stop making all the vulns public.
Norphesius@reddit
The data centers are for hype-derived projections of usage. AI companies need to maintain the hype at all costs, or else they lose investor funding and implode. These companies are offering their services at an unprofitable rate, sustained by investor hype money, so they can corner the market and get a ton of users hooked on using their product. Once one of them crowds out the others and becomes dominant they'll jack up their prices and rake in the profits from the customers that can no longer function without AI.
That's the plan at least, though I don't think that's how it's going to play out. What's more likely is the bubble popping and a lot of these companies (or at least their AI divisions) will collapse. After that who knows.
lelanthran@reddit
Depressing thoughts indeed :-(
In the early 2000's we had a joke "XML is like violence - if it doen't work, use more"
Now we have "AI is like violence - if it doesn't work, use more".
TomWithTime@reddit
It's already happening at my job. I asked for advice on reviewing the 10k+ line PRs, that can now be churned out every few days, in a reasonable amount of time. Unfortunately that was the answer - make ai review the pull request, ask it to highlight specific things and then human review those handful of things.
And I guess we find out the rest from production exploding later. I've invested a lot of time in reviewing my own ai assisted PRs because I care about what I'm putting out, and the ai usually makes a few small mistakes in very large changes. Caught one the first time that would have prevented us from serving any new customers if it went through. Caught one this week that was reading a feature flag in the wrong place so it would have turned the entire system off if this feature flag for 1 part of it was not set.
I think reading the code isn't enough. Even if the tools become mostly flawless, that 1 critical error per 10,000 lines changes is going to kill your business eventually. I think a business with a lot of ai written code is going to need a test environment that tests the entire system end to end every time there is a release. My business has talked about that before, but unfortunately the ai era arrived before we could set that up.
vips7L@reddit
Just stop caring. Let it burn man. It's the only way the suits will learn.
GeneralSEOD@reddit
I'm sure the people that ran businesses on paper and pen, thought the same about trusting computer systems with their documents.
I hate it as much as the next person. But it is the next revolution. I've been using Claude/Codex to fully plan and integrate with then code reviews happening from both myself and AI, and honestly. It does a pretty good job.
This is web dev though. I think the one thing lost is my ease of integrating AI is not the same as a developer working on Unreal Engine 6 for example.
Walkier@reddit
Or maybe writing bulletproof software is just really really hard. And finding ways to break it is not, relatively speaking. Hopefully it doesn't end up that way.
imp0ppable@reddit
I mean it is legitimately harder when your project is written in C. Had curl been written in Go or Rust it would be less vulnerable but whether there is lack of flexibility or other problem in them that means nobody has been able or willing to port the likes of curl to them, i don't know.
Uristqwerty@reddit
Much of Rust's safety comes from well-thought-out libraries carefully encoding preconditions and postconditions in types, so that the compiler helps ensure programs using that library are doing so properly.
It's going to be just as hard to write the library itself, just with a different distribution of where you're spending most of the effort.
gen2brain@reddit
Had Curl been written in Go or Rust, only Go or Rust libraries would use it; it would be known only in those circles, not in the whole ecosystem/planet. C API remains the most important one. At least for now, but every new hardware gets assembly and C support, not Go or Rust support.
Valuable_Leave_7314@reddit
Rust has really solid interoperability with the C ABI through FFI. You can write a library in Rust, compile it into a shared object, and export standard C headers. To the end user and the operating system, it just looks like a normal C library, but under the hood you still get Rusts memory safety guarantees
rustls-ffi is a pretty clear example that this approach is completely viable in practice.
gen2brain@reddit
You can do the same in Go, compile to c-shared library, a c-static, export functions to C ABI. But, at that point, what is the point? Just use C where you need C.
imp0ppable@reddit
Are you saying that you can compile a C compatible module from Rust or Golang code? Because you absolutely can. Curl has they hyper backend already although it's had some issues (I'm not following closely).
Memory safety is definitely the way forward and we don't need to rewrite curl (although some are trying e.g. https://github.com/jonwiggins/urlx) just the exposed parts where most of the exploits are found.
Chroiche@reddit
I think curl ditched hyper support last I heard
RyanCacophony@reddit
I can tell you - this is already happening.
putin_my_ass@reddit
I'm not sure this is how it will go. AI tokens will get more and more expensive, I think there will be a divide where many folks carry on doing things the "old hard way" and make great software simply because it's economical.
seamustheseagull@reddit
This should all calm down in a couple of years.
At the moment most of this noise is being created by bots and resume factories attempting to build up someone's credentials to make them look like a great hire.
Once hiring moves away from, "How many open source projects do you contribute to?" and companies start cancelling their bug bounty programmes, this noise will go away.
lookmeat@reddit
You're right but not for the reasons you claim.
LLMs crossed a boundary that is allowing them to be decent enough at finding bugs. Also I'd argue that the bot phase has passed: if I see someone with a lot of security bugs I'll go deep until subject, if I realized this was an AI slop spammer they'd get a strong no hire automatically. Also must bounty programs ended or added enough filters to avoid spamming strategies.
What I suspect we're seeing now is engineers, researchers and students using LLMs as tools and identifying new vulnerabilities that would have been hard for a human alone to see. See LLMs see code very differently to humans, they don't understand what the code really is, but they see the patterns in the text itself, they can identify problematic patterns that humans normally wouldn't look at (especially in good, readable code, in a twist): it's like those color blindness tests where you see a different number of you have a certain color blindness or none. You still need a human to comb through this patterns and decide what is real or not, and build a deeper report.
So right now we're seeing the rush, the code has accumulated insidious bugs in 30 years of work on it, and only now it's all being revealed at the same time. Going in further you'll catch these class of bugs as they appear, rather than letting them all pile together.
Torgard@reddit
It's also that it's tedious work. It would be different if it could be a huge global hackathon funded by the AI companies, where you'd just throw the tools at the codebase. Let's all collectively stop working on anything else, and just up and fix the big open-source projects. Not possible at all, of course.
The AI companies could at least throw piles of money at curl, that would be the proper thing to do.
lookmeat@reddit
Oh the situation is messy and companies that depend on curl should throw money, because otherwise a bush hat hacker could rediscover on if these vulnerabilities using AI as well. It's a security liability not too. And yes this includes all AI companies.
But my point is that things will improve as we won't get a backlog of hidden bugs suddenly uncovered by AI for the first time, instead we'll catch these as they are introduced.
Valuable_Leave_7314@reddit
Bug bounty programs aren’t going anywhere, because for companies it’s still cheaper to pay a researcher $ 500 for an ai-discovered bug than to deal with the fallout of a real production breach
markehammons@reddit
Not really, he's saying the load is coming from more and more high-quality bug analysis and reports. That's good, but his team and he are not being funded in the amount needed to properly address these issues. This isn't AI ruining things, this is companies who depend on curl the world over taking advantage and refusing to chip in the bare minimum to maintain the commons. I hate to say it, but this is in effect because of the MIT license. It provides no mechanism to fight freeloading in the least.
Ravek@reddit
More than one security report per day? Yikes, sounds like no one should use curl then.
PerkyPangolin@reddit
That's your takeaway from the article?
Ravek@reddit
Software that apparently has thousands of security bugs is something you’re happy to use?
PerkyPangolin@reddit
The "thousands of security bugs" are a 30-year cumulative count of issues found and fixed - not ignored - thanks to curl being one of the most scrutinized, fuzzed, and verified codebases on the planet. They’re receiving around one report per day, with almost all vulnerabilities rated LOW or MEDIUM severity, and the last HIGH was in 2023 (which you should have know, if you've read the article). Every bug reported means a bug fixed, and the flood of reports is a sign of relentless security work, not neglect. But sure, panic about the project that actively and transparently hunts down and patches its issues. The project multiple instance of which helped you post your "take" here.
Ravek@reddit
If new bugs are being discovered every single day and have been for a while, that suggests the codebase is a complete mess. If you paved a road with a thousand broken stones, should you be commended that you fix one stone every day?
PerkyPangolin@reddit
Your road analogy is nonsense. Software isn’t a static pile of stones - it’s a living system that evolves, faces new threats daily, and runs across countless platforms and protocols. The "endless bugs" are endless discoveries from relentless scrutiny and better tools, which is exactly what you want from security-conscious software. Most are low-severity, as pointed out before, all get fixed quickly. Again, you're criticizing the project for being thorough instead of the ones shipping unaudited code and hoping for the best.
And I find it wild your writing this about Curl of all things.
What software are you shipping that's forever free of bugs in a constantly changing context?
Ravek@reddit
What you want from good software is an endless supply of security bugs that are discovered? I'd want good security by construction. How can you put your trust in software that constantly has new problems popping up?
What a silly false dichotomy.
troublemaker74@reddit
The reason why there are so many is because there's a bug bounty program that receives avalanches of slop.
Curl is the most secure and ubiquitous HTTP library/utility that I am aware of.
Ravek@reddit
The author of curl seems to disagree with you. Apparently it has new security bugs popping up every day.
PerkyPangolin@reddit
I don't think there's a bug bounty anymore: - https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/
_x_oOo_x_@reddit
Who says all those reports are valid and even if so, don't have thousands of duplicates?
Ravek@reddit
Did I miss the part where he mentioned any of that?
backfire10z@reddit
Feel free to write a bug-free fork and release it to the public. Nobody is stopping you.
_x_oOo_x_@reddit
I'm sure this blog post is great but when you post something to reddit or anywhere really - people with absolutely no context will see it. I have no idea what something titled "The pressure" will be about and have no reason to click it. I assume it's not an essay about plumbing. The only other piece of context is the URL.. Daniel.haxx - okay, I've heard this name before - he write
curl, right? If you provided a title or description briefly outlining what the essay is about many more people might click, just sayingAiexReddit@reddit
I really appreciate that Daniel takes the time to write these great blog posts despite how overwhelmingly busy he is.
I feel like they're often a strong foreshadowing of my own experience (obviously to a lesser degree) in my own work and organization.
I have experienced many of the same things he has described in his blogs over the past year and gone through the same phases, including this one where as recently as today I was describing to some folks the experience of dealing with what now feels like an endless influx of content and code that is for all intents and purpose correct, but requires enormous effort and focus to validate that correctness, and it's starting to feel completely unsustainable to manage without burning out.
Interesting times ahead indeed.
idebugthusiexist@reddit
Totally understandable