2025-09-10 13:49:32
Welcome to one of the more feature-packed curl releases we have had in a while. Exactly eight weeks since we shipped 8.15.0.
the 270th release
17 changes
56 days (total: 10,036)
260 bugfixes (total: 12,538)
453 commits (total: 36,025)
2 new public libcurl function (total: 98)
0 new curl_easy_setopt() option (total: 308)
3 new curl command line option (total: 272)
76 contributors, 39 new (total: 3,499)
32 authors, 17 new (total: 1,410)
2 security fixes (total: 169)
We publish two severity-low vulnerabilities in sync with this release:
We have a long range of changes this time:
--follow option
--out-null option
--parallel-max-host option to limit concurrent connections per host--retry-delay and --retry-max-time accept decimal seconds--longopt=value
NETRC environment variable (first) if setThe official bugfix count surpassed 250 this cycle and we have documented them all in the changelog, including links to most issues or pull-requests where they originated.
See the release presentation for a walk-through of some of the perhaps most interesting ones.
2025-09-09 14:57:52
One of these mantras I keep repeating is how we in the curl project keep improving, keep polishing and keep tightening every bolt there is. No one can do everything right from day one, but given time and will we can over time get a lot of things lined up in neat and tidy lines.
And yet new things creep up all the time that can be improved and taken yet a little further.
Back in the spring of 2025 we had an exercise at our curl up meeting in Prague. Jim Fuller played up an imaginary life-like scenario for a bunch of curl maintainers. In this role played major incident we got to consider how we would behave and what we would do in the curl project if something like Heartbleed or a serious breach occur.
It was a little of an eye opener for several of us. We realized we should probably get some more details written down and planned for.
We of course arrange for things and work on procedures and practices to the best of our abilities to make sure that there will never be any such major incident in the curl project. However, as we are all human and we all do mistakes, it would be foolish to think that we are somehow immune against incidents of the highest possible severity level. Rationally, we should just accept the fact that even though the risk is ideally really slim, it exists. It could happen.
We have now documented some guidelines about what exactly constitutes a major incident, how it is declared, some roles we need to shoulder while it is ongoing, with a focus on both internal and external communication, and how we declare that the incident has ended. It’s straight forward and quite simple.
Feel free to criticize or improve those if you find omissions or mistakes. I imagine that if we ever get to actually use these documented steps because of such a project-shaking event, we will get reasons to improve it. Until then we just need to apply our imagination and make sure it seems reasonable.
2025-09-08 15:10:50
This was the title of my keynote at the Open Source Summit Europe 2025 conference in Amsterdam that I delivered on August 25, 2025.
The giants, as in fact large parts of modern infrastructure, stand on the shoulders of Open Source projects and their maintainers. But maybe these projects and people are not treated in optimal ways.
The slides are available.
My slot allowed me 15 minutes and I completed my presentation with around two minutes left. I have rarely received so many positive comments as after this talk.
The painting in the top image, The Colossus (also known as The Giant), is traditionally attributed to Francisco de Goya but might actually have been made by his friend Asensio Juliá.
2025-08-29 04:52:56
curl added support for OpenSSL immediately when it was first released, as they switched away from SSLeay, in the late 1990s.
We have since supported it over the decades as both OpenSSL and curl have developed.
A while back the OpenSSL project stopped updating their 1.0.x and 1.1.x public branches. This means that unless you are paying for support from someone, and only relies on the public open versions these OpenSSL releases are going to decay and soon be insecure choices. Nothing to rely on.
As a direct result of this, the curl project has decided to drop support for OpenSSL 1.0.2 and 1.1.1 soon.
We stop supporting OpenSSL 1.0.2 in December 2025.
We stop supporting OpenSSL 1.1.1 in June 2026.
Starting in June 2026, we plan to only support OpenSSL 3 and later. Of course with the caveat that we might change our minds or schedule as we go along and things happen.
All pending removals from curl are listed here.
Part of the reason for us dropping this support is the fact that basically only users who are already paying for OpenSSL support are the ones who are going to be using these versions.
We will offer commercial support for curl with OpenSSL 1.1.1 for as long as customers want it, even when support gets removed from the public curl version.
This news is for OpenSSL support only and does not affect the forks. We intend to keep supporting the whole fork family AmiSSL, AWS-LC, BoringSSL, LibreSSL and QuicTLS going forward as well.
2025-08-18 13:45:30
In August 16 2025 I did a keynote with this title on the FrOSCon conference in Bonn, Germany. The room held a few hundred seats and every single one was occupied with people also filling up the stairs and was standing along the walls. Awesome!
See also my death by slop post for more background.
The slides are available here.
2025-08-15 14:28:55
Seven years ago I wrote about how a hundred million cars were running curl and as I brought up this blog post in a discussion recently, I came to reflect over how the world might have changed since. Is curl perhaps used in more cars now?
Yes it is.
With the help of friendly people on Mastodon, and a little bit of Googling, the current set of car brands known to have cars running curl contains 47 names. Most of the world’s top brands:
Acura, Alfa Romeo, Audi, Baojun, Bentley, BMW, Buick, Cadillac, Chevrolet, Chrysler, Citroen, Dacia, Dodge, DS, Fiat, Ford, GMC, Holden, Honda, Hyundai, Infiniti, Jeep, Kia, Lamborghini, Lexus, Lincoln, Mazda, Mercedes, Mini, Nissan, Opel, Peugeot, Polestar, Porsche, RAM, Renault, Rolls Royce, Seat, Skoda, Smart, Subaru, Suzuki, Tesla, Toyota, Vauxhall, Volkswagen, Volvo
I think it is safe to claim that curl now runs in several hundred million cars.
This is based on curl or curl’s copyright being listed in documentation and/or shown on screen on the car’s infotainment system.
The manufacturers need to provide that information per the curl license. Even if some of course still don’t.
For brands missing in the list, we don’t know their status. There are many more car brands that we can suspect probably also run and use curl, but for which we have not found enough evidence for it. If you do, please let me know!
These are all using libcurl, not the command line tool. It is not uncommon for them to run fairly old versions.
I can’t tell for sure as they don’t tell me. Presumably though, a modern care does a lot of Internet transfers for all sorts of purposes and curl is a reliable library for doing that. Download firmware images, music, maps or media. Upload statistics, messages, high-scores etc. Modern cars are full-blown computers plus mobile phones combined, of course they transfer data.
The list contains 47 brands right now. They are however manufactured by a smaller number of companies, as most car companies sell cars under multiple different brands. So maybe 15 car companies?
Additionally, many of these companies buy their software from a provider who bundles it up for them. Several of these companies probably get their software from the same suppliers. So maybe there is only 7 different ones?
I have still chosen to list and talk about the brands because those are the consumer facing names used in everyday conversations, and they are the names we mere mortals are most likely to recognize.
Ironically enough, while curl runs in practically almost every new modern car that comes out from factories, not a single of the companies producing the cars or the software they run, are sponsors of curl or customers of curl support. Not one.
We give away curl for free for everyone to use at no cost and there is no obligation for anyone to pay anyone for this. These companies are perfectly in their rights to act like this.
You could possibly argue that companies should think about their own future and make sure that dependencies they rely on and would like to keep using, also survive so that they can keep depending on these components going forward as well. But obviously that is not how this works.
curl is liberally licensed under an MIT-like license.
I want curl to remain Open Source and I really like providing it in a way, under a liberal license, that makes it possible to get used everywhere. I mean, if we use the measurement of how widely used a software is, I think we can agree that curl is a top candidate.
I would like the economics and financials around the curl project to work out anyway, but maybe that is a utopia we can never reach. Maybe we eventually will have to change the license or something to entice or force a different behavior.
