Stenberg: The pressure [LWN.net]

Curl maintainer Daniel Stenberg writes about the stress of keeping up with the current flood of security reports.

This is a never-before seen or experienced pressure on the curl project and its security team members. An avalanche of high priority work that trumps all other things in the project that is primarily mental because we certainly could ignore them all if we wanted, but we feel a responsibility, we have a conscience and we are proud about our work. We feel obliged to fix security problems in the software we have helped shipped to every device on the globe. This is personal to us.
With about half the release cycle left until the pending release ships, we already have twelve confirmed vulnerabilities meaning twelve pending CVE announcements. That's a new project record and it also means we will reach thirty published CVEs in 2026 even before half the calendar year has passed. The projected total amount of curl CVEs published through the whole year is therefore at least double this number!

to post comments

Revealing

Posted May 26, 2026 15:14 UTC (Tue) by gmprice (subscriber, #167884) [Link] (11 responses)

If nothing else, the whole LLM experiment is revealing the general under-investment in maintaining open source projects that are the bedrock of the internet as a whole.

Revealing

Posted May 26, 2026 15:38 UTC (Tue) by demiguru (guest, #176724) [Link] (10 responses)

I could not agree more. That being said, how many less active open source projects can now be more easily maintained by LLM like platforms?

Revealing

Posted May 26, 2026 15:50 UTC (Tue) by pizza (subscriber, #46) [Link]

> I could not agree more. That being said, how many less active open source projects can now be more easily maintained by LLM like platforms?

....Depends on what you mean by "maintained"

Revealing

Posted May 26, 2026 15:50 UTC (Tue) by gmprice (subscriber, #167884) [Link] (8 responses)

None. Maintaining software is not a mechanical job, it's human one.

LLMs cannot replace the fundamentally human part of software development.

I.e.: "What do we want this software to do" and more importantly "What do we want this software to *not* do".

Revealing

Posted May 26, 2026 17:04 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (7 responses)

I.e.: "What do we want this software to do" and more importantly "What do we want this software to *not* do".

It depends on where the project is in its lifespan. "What do we want this software to do/not do" is mostly a question for a project that's still adding features. If the project isn't adding features- and a lot of the kind of projects that are chronically short on developer time aren't- it's mostly made up its mind about what it will and won't do. In that case, the main job is dealing with bugs and maintaining compatibility with any changes in dependencies. There is some question about what exactly classifies as a bug- it does require judgment about whether the alleged behavior is intended or not- but even that is less of an issue with security bugs.

Getting back to the original question, I suspect most less active projects will find LLM bug finding to be a bad thing overall. They're less active either because they're in maintenance mode or because the developer just doesn't have time to do more. Either way, a sudden flood of bug reports is likely to be overwhelming. Meanwhile, the developer wasn't doing a whole lot with the project already, so being able to spend a little less time on it once the flood of bugs is dealt with won't be much consolation.

Revealing

Posted May 26, 2026 20:17 UTC (Tue) by gmprice (subscriber, #167884) [Link] (5 responses)

I realize this is an exercise in being a pedant - but...

> maintaining compatibility with any changes in dependencies

This is feature development.

On the note of bugs: The difference between a feature and bug is simply the desirability of some behavior :D

Revealing

Posted May 27, 2026 15:37 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (4 responses)

This is feature development.

Not necessarily. A distressing number of languages and libraries deprecate features without adequate consideration of their users, and programs that use them have to change to remain functional. Developers who use those dependencies have to update their programs without actually adding anything useful to end users just to keep up. That's code churn, not feature development.

Revealing

Posted May 27, 2026 22:38 UTC (Wed) by gmprice (subscriber, #167884) [Link] (3 responses)

Support for some underlying library version changing is a feature. I will die on this hill.

Revealing

Posted May 28, 2026 7:37 UTC (Thu) by NAR (subscriber, #1313) [Link]

Well, what if the underlying library version change comes with the "All users [...] must upgrade" message? Because "security reasons"?

Revealing

Posted May 28, 2026 8:03 UTC (Thu) by taladar (subscriber, #68407) [Link]

I wouldn't go that far if it is truly only the version that changes and no other changes to the code using the library is necessary beyond specifying the use of the new library version, recompiling, running the test suite/manual testing and releasing your own new version.

However I am with you if there are necessary changes to the code using the library.

Revealing

Posted May 29, 2026 6:56 UTC (Fri) by jrn (subscriber, #64214) [Link]

What does that mean in practical terms? Lacking bugs is a feature, too.

Revealing

Posted May 27, 2026 8:04 UTC (Wed) by taladar (subscriber, #68407) [Link]

Even projects not adding features often actively consider and reject new features (e.g. compatibility with some new network protocol or storage format, support for colors, links, unicode,... in terminal output or input). This is still a fundamentally human task.

Just 12 vulnerabilities?

Posted May 26, 2026 15:49 UTC (Tue) by cyperpunks (subscriber, #39406) [Link] (6 responses)

That's not that much? In large project like database software I would assume over several thousand issues.

Just 12 vulnerabilities?

Posted May 26, 2026 15:56 UTC (Tue) by hailfinger (subscriber, #76962) [Link] (5 responses)

For a project the size of curl, the number of CVEs found in curl is pretty low. That may be a strong indicator for high code quality.

Just 12 vulnerabilities?

Posted May 26, 2026 16:12 UTC (Tue) by ballombe (subscriber, #9523) [Link] (4 responses)

Especially since network tools are magnets for CVE...
Daniel Stenberg deserves to be commended for the way he maintained curl since the first release in 1996.

Just 12 vulnerabilities?

Posted May 26, 2026 19:58 UTC (Tue) by DouglasJM (subscriber, #6435) [Link] (3 responses)

I would definitely second that recommendation!

Just 12 vulnerabilities?

Posted May 27, 2026 13:24 UTC (Wed) by ryanduve (subscriber, #127786) [Link] (2 responses)

Three makes a quorum.

Daniel Stenberg, by the power vested in me by my annual LWN subscription payment and the virtue of being the [arbitrarily] third commenter in this nested subconversation, I hereby officially commend you for the maintenance you've put into curl since the days when doing the Macarena was fashionable. Thank you for providing us, all of us, a sane, solid command line API, and a library underneath to match, for sending and receiving messages across the internet for decades. We are an innately sour bunch by nature, and often forget when to say thanks, so please consider this an attempt to partially fill in that gap: thank you and your whole team for what you all do. Even though we don't say it as much as we mean to, you are appreciated!

Just 12 vulnerabilities?

Posted May 29, 2026 8:08 UTC (Fri) by sdalley (subscriber, #18550) [Link]

Ja, den förtjänar en ordentlig skål!

Just 12 vulnerabilities?

Posted Jun 5, 2026 13:34 UTC (Fri) by bagder (guest, #38414) [Link]

Wow. Thank you!