2025-07-16 14:29:21
Welcome to another curl release. A shorter cycle this time so we did not have time to merge many changes: there is just one logged. See below.
This is the 269th release featuring 269 command line options.
the 269th release
1 change
42 days (total: 9,980)
233 bugfixes (total: 12,282)
334 commits (total: 35,572)
0 new public libcurl function (total: 96)
0 new curl_easy_setopt() option (total: 308)
0 new curl command line option (total: 269)
57 contributors, 29 new (total: 3,460)
37 authors, 16 new (total: 1,392)
0 security fix (total: 167)
Removed support for Secure Transport and BearSSL.
We manage to yet again land over 230 documented bugfixes (5.5 per day!). Read about them in the full changelog. A set of them are discussed in the release video.
2025-07-14 18:38:17
I have previously blogged about the relatively new trend of AI slop in vulnerability reports submitted to curl and how it hurts and exhausts us.
This trend does not seem to slow down. On the contrary, it seems that we have recently not only received more AI slop but also more human slop. The latter differs only in the way that we cannot immediately tell that an AI made it, even though we many times still suspect it. The net effect is the same.
The general trend so far in 2025 has been way more AI slop than ever before (about 20% of all submissions) as we have averaged in about two security report submissions per week. In early July, about 5% of the submissions in 2025 had turned out to be genuine vulnerabilities. The valid-rate has decreased significantly compared to previous years.
We have run the curl Bug Bounty since 2019 and I have previously considered it a success based on the amount of genuine and real security problems we have gotten reported and thus fixed through this program. 81 of them to be exact, with over 90,000 USD paid in awards.
While we are not going to do anything rushed or in panic immediately, there are reasons for us to consider changing the setup. Maybe we need to drop the monetary reward?
I want us to use the rest of the year 2025 to evaluate and think. The curl bounty program continues to run and we deal with everything as before while we ponder about what we can and should do to improve the situation. For the sanity of the curl security team members.
We need to reduce the amount of sand in the machine. We must do something to drastically reduce the temptation for users to submit low quality reports. Be it with AI or without AI.
The curl security team consists of seven team members. I encourage the others to also chime in to back me up (so that we act right in each case). Every report thus engages 3-4 persons. Perhaps for 30 minutes, sometimes up to an hour or three. Each.
I personally spend an insane amount of time on curl already, wasting three hours still leaves time for other things. My fellows however are not full time on curl. They might only have three hours per week for curl. Not to mention the emotional toll it takes to deal with these mind-numbing stupidities.
Times eight the last week alone.
On HackerOne the users get their reputation lowered when we close reports as not applicable. That is only really a mild “threat” to experienced HackerOne participants. For new users on the platform that is mostly a pointless exercise as they can just create a new account next week. Banning those users is similarly a rather toothless threat.
Besides, there seem to be so many so even if one goes away, there are a thousand more.
It is not super obvious to me exactly how HackerOne should change to help us combat this. It is however clear that we need them to do something. Offer us more tools and knobs to tweak, to save us from drowning. If we are to keep the program with them.
I have yet again reached out. We will just have to see where that takes us.
People mention charging a fee for the right to submit a security vulnerability (that could be paid back if a proper report). That would probably slow them down significantly sure, but it seems like a rather hostile way for an Open Source project that aims to be as open and available as possible. Not to mention that we don’t have any current infrastructure setup for this – and neither does HackerOne. And managing money is painful.
Dropping the monetary reward part would make it much less interesting for the general populace to do random AI queries in desperate attempts to report something that could generate income. It of course also removes the traction for some professional and highly skilled security researchers, but maybe that is a hit we can/must take?
As a lot of these reporters seem to genuinely think they help out, apparently blatantly tricked by the marketing of the AI hype-machines, it is not certain that removing the money from the table is going to completely stop the flood. We need to be prepared for that as well. Let’s burn that bridge if we get to it.
If you are still innocently unaware of what AI slop means in the context of security reports, I have collected a list of a number of reports submitted to curl that help showcase. Here’s a snapshot of the list from today:
libcurl Cookie Management (cookie.c) #3117697
CURLOPT_CUSTOMREQUEST Verb Tunneling #3231321
2025-07-13 17:21:13
A while ago I received an email with this question.
I’ve been subscribed to your weekly newsletter for a while now, receiving your weekly updates every Friday. I’m writing because I admire your consistency, focus, and perseverance. I can’t help but wonder, with admiration, how you manage to do it.
Since this is a topic I receive questions about semi-regularly, I decided I would attempt to answer it. I have probably touched the subject in previous blog posts as well.
Let me start out by defining what I consider my primary work to be. Or perhaps I should call it my mission because it goes way beyond just “work”. curl is irrevocably a huge part of me and my life.
As a successful Open Source project I acknowledge and am aware that we (I mean curl) might get more attention than some others, and that we are used as or considered a “model” sometimes, making it even more important to do things right. From my language use in public to source code decisions. I try to live up to these expectations.
A part of my job is to make companies become paying customers so that I can afford working on curl – and once they have become customers I need to every now and then attend to support tickets from them. I can work full-time on curl thanks to my commercial customers.
I have a strong sense of loyalty and commitment. When I join a project or a cause, I typically stick around and do my share of the job until it is finished.
I enjoy programming and software development – and I have done so ever since I first learned about programming as a teen in the mid 1980s. It is fun to create something that is useful and that can be used by others, but I also like solving the puzzles and challenges that come up in the process.
When the software project you work on never finishes, and is used by a crazy amount of users it gives you a sense of responsibility and pride. An even bigger incentive to make sure it actually works as intended. A desire to please the users. All the users.
Even after having reached many billions of installations there are still challenges to push the project further and harder on every possible front. Make it the best documented one. Make it an exemplary Open Source project. Make it newcomer friendly. Add more tests. Make sure not a single project in the world can claim they ship better security advisories. Work really hard on making it the most secure network library there is. While at the same being welcoming and friendly to new contributors.
If there is any area that curl is not best-in-class, we should put in more work and improve curl in that area. While at the same time keep up and polish it in all other aspects.
This is what drives me. This is what I want.
Getting top scores in every possible (imaginary and real) scorecard is accomplished through good old engineering. Do the job. Test. Iterate. Fail. Fix. Add tests. Do it again. Over and over.
A normal work day I sit down at my desk at about 8 in the morning and start. I iterate over issues, pull-requests and the everyday curl maintenance. I post silly messages on Mastodon and I chat with friends on IRC.
I try to end my regular work days at around 18:00, but I may go longer or shorter some days depending on what I feel like or if it’s “floorball day”. (I leave early on Wednesdays to go play with friends.)
As I live in Sweden and have many North-American colleagues and customers, I have occasional evening meetings to deal with the nine hour time difference to their west coast.
At some time between 22:00 and 23:00 I sit down in front of my computer again for the evening shift. I continue working on issues, fix bugs and review pull-requests. At 1am I sleep.
It makes me do maybe 50-55 hours of work per normal week. I call it all work hours plus plenty of spare time. Because this is the passion of my life. It is my job and my hobby. Because I want to. I love it. It is not a setup and number of hours I ask nor expect anyone else to do.
I have worked like this since early 2019 when I started doing curl full-time.
One explanation how this all works is that curl is independent. Truly independent in most senses of the word.
No companies control or own curl in any way. Yet every company is welcome to participate.
curl is not part of any foundation or umbrella organization. We range free.
curl is extremely liberally licensed.
One of the hardest questions to answer is how I can keep up the motivation and still consider this fun and exciting after all this time.
First let’s not pretend that it always feels fun and thrilling. Sometimes it actually feels a bit boring and done. There is no shame in that and it is not strange or odd. Such periods come and go. When they come, I might do less curl for a while. Or maybe find a corner of the project that is not important but could be fun to poke at. I have learned that these periods come and go.
What motivates me is that everyone runs and uses curl and libcurl. Positive feedback is fuel that can keep me running for a long time. Making curl a leading tool that shoulders and carries a lot of digital infrastructure makes me feel a purpose. When there is a bug reported, I can feel almost hurt and sometimes ashamed and I need to get it fixed. curl is supposed to be one of the best in all categories and if it ever is not, I will work hard on making it so.
The social setup around Open Source and a success such as curl also makes it fun. I work full-time from home without geographical proximity to any other curl regulars. But I don’t need that. We can joke around in chat, we help each other in issues and pull-requests and we can do bad puns in video meetings. Contrary to “normal” job colleagues, these people are here because they want, believe and strive for something similar to me – and they are spread out across the world.
I feel that I work for the curl users. The users doing internet transfers. As opposed to any big company, tech giants or anyone else who could otherwise dictate direction. It’s highly motivational to be working for the users. Sure, the entities paying my wages are primarily a few huge companies, but the setup still makes this work and I still feel and act on the users behalf. Those companies have exactly no say in how we run the Open Source project.
I take criticism about curl personally because I have put so much of myself into it and as the BDFL for decades a lot of what it is today is ultimately the result of my choices.
I try to lead by example. I still do a fair amount of development, debugging and architectural design in the project. I follow and perform the same steps I expect from the other contributors.
I’m a believer in lowering friction in the project, but still not relaxing the requirements: we still need tests and documentation for everything we do. Entering the project should be easy and welcoming, even if it can be hard to actually get a change merged.
I believe in reducing bureaucracy and formalities so that we can focus on development and getting things done. We don’t have or need manager levels or titles. We have things to do, people who do things and we have people that can review, comment and eventually merge those improvements. If there are fewer people participating during periods, then things just get done slower.
I invite discussions and participation and I encourage the same approach from my fellow contributors. When we want to do things, change things, improve things, we should inform and invite the greater community for comments, feedback and help. Oftentimes they may not have a lot to say, but we should still continue to ask for their opinions.
I use a direct and non-complicated communication style. I want to be friendly, I don’t curse, I focus on speaking about their suggestions and not the person. To the point rather than convoluted. When insulted, I try to not engage (which I sometimes fail at). But I also want to have a zero tolerance policy against bad behavior and abuse to enable the positive spirit to remain.
Like everyone else, I sometimes fail in my ambitions of how I want to behave and lead the project. Hopefully that happens less and less frequently over time.
I think most of what has made curl good and successful has happened because I and the team around curl have worked hard on making it so. It has not happened by chance or by accident.
I have a loving and understanding family. My wife and I celebrated our 25th anniversary earlier this year. My two kids are grown-ups now – both were born after I started working on curl.
2025-07-12 21:13:25
I need to get myself a new laptop. My existing one is from 2017 and was already then not the most powerful one.
It recently started to shut itself off when running on battery and during the two most recent curl up meetings it has proven itself to be rather sluggish and unable to save a live camera-recording while also streaming it, without stuttering or having other problems.
I plan to get a new 13″ one from Framework, and a semi-beefy one from there runs at about 2,500 USD. I’m looking at roughly this configuration.
For the first time ever, the curl fund is going to help pay for this. The curl fund is all donations and sponsorships gathered. Money we only spend to improve curl and curl related activities. All my machines I have ever used to develop curl on up until now have been paid for by me personally.
For this special occasion, we have created a small “crowd-source” like effort. You can help sponsor me this device and we have special little collectors pool for it here:
https://opencollective.com/curl/contribute/laptop-90642
If we get more than 1,000 USD donated to this, I can upgrade my laptop config. More CPU, more memory, more storage perhaps.
If this effort gets less than 1,000 donated, then I will stick to with the original “base” setup.
For everyone who donate 200 USD (or more) I offer space on the laptop cover for the donor to decide exactly what I should put there (in terms of stickers etc).
This program will run for a week as a start.
I do my main curl development on a desktop PC in my home office. I use my laptop primarily when away, on travels and on vacations. I bring it to talks (10-15 a year) where I typically talk about curl or curl adjacent topics. I occasionally use it to live-stream with, like from our annual curl up meetings.
I have decided to go with Framework because I like their concept and I hear good things about them.
I run Linux. I prefer Debian. That is what I intend to use on this one as well.
We have a few regular gracious sponsors of the curl project that donates money to us on a regular basis. Their money is what pays for this if nobody else wants to participate.
It took nine minutes after I published this to get the first 200 USD donation.
We reached 1,000 USD already within the first hour. I am looking at upgrading the setup. Starting probably with the CPU.
90 minutes in “A friendly golem” changed the game when they donated 1,750 USD in one go and we are at a total of 3,770 USD! I think I can max up the config now.
July13, 17:21: The order has been placed. Said to be delivered within 5 days.
Thank you everyone for chipping in. Truly amazing. I will keep you posted on the thing and follow up with some photos and a review later.
2025-07-11 23:35:05
With the new EU legislation Cyber Resiliency Act (CRA), there are new responsibilities and requirements put on manufacturers of digital products and services in Europe.
Going forward these manufacturers must be able to know and report the exact contents of their software, called a Software Bill of Material (SBOM) and they have requirements to check for vulnerabilities in those components etc. This implies that they need to have full control and knowledge about all of their Open Source components in their stack. (See the CRA Hub for a good resource on CRA for Open Source people.)
As a maintainer of a software component that is widely used, I have been curious to see how this will materialize for us. Today I got a first glimpse of what I can only guess will happen more going forward.
This multi-billion-dollar Fortune-500 company that I have no contract with and with which I have had no previous communication, sent me this email asking for a lot of curl information. A slightly redacted version is shown below.
Now that my curiosity has been satisfied a little bit I instead await the future and long to see how many more of these that will come. And how they will respond to my replies.
CRA_request_counter = 1;
Hello,
I hope this message finds you well.
As part of our ongoing efforts to comply with the EU Cyber Resilience Act (CRA), we are currently conducting a cybersecurity risk assessment of third-party software vendors whose products or components are integrated into our systems.
To support this initiative, we kindly request your input on the following questions related to your software product “libcurl” with version 7.87.0. Please provide your responses directly in the table below and do reply to all added in this email,
Additional Information:
- Purpose: This security assessment is part of our due diligence and regulatory compliance obligations under the EU CRA.
- Confidentiality: All information shared will be treated as confidential and used solely for the purpose of this assessment.
- Contact: Should you have any questions or need further clarification, please feel free to reach out by replying directly to this email.
We kindly request your response by Friday, July 25, 2025, to ensure timely completion of our assessment process. Thank you for your cooperation and continued partnership in maintaining a secure and resilient digital environment.
I am not their vendor without having a more formal relationship established and I am certainly not going to spend a few hours of my spare time gathering a lot of information for them for free for their commercial benefit.
They “kindly” want me to respond within two weeks.
Their use of double quotes around “libcurl” feels odd, and they claim to be using a version that is now more than 2.5 years old.
Most if not all of the information they are asking for is already publicly and openly accessible and readable. I suspect they want the information in this more formal way to make it appear more reliable or trustworthy perhaps. Or maybe it just follows their processes better.
(It also reminded me of the NASA emails.)
I responded like this
Hello,
I will be happy to answer all curl and libcurl related questions and assist you with this inquiry as soon as we have a support contract setup. You can get the process started immediately by emailing [email protected].
Thanks, I’m looking forward to future cooperation.
/ Daniel
I will let you know if they take me up on my offer .
This snapshot of how it looked also shows the actual nine-question form table.
I’m looking forward to eventually do business with this company, I don’t want them to feel targeted or “ridiculed”. I also suspect that there will be many more emails like this going forward. The company name is not the interesting part of this story.
2025-07-10 16:06:57
This is an intersection of two of my obsessions: graphs and vulnerability data for the curl project.
In order to track and follow every imaginable angle of development, progression and (possible) improvements in the curl project we track and log lots of metadata.
In order to educate and inform users about past vulnerabilities, but also as a means for the project team to find patterns and learn from past mistakes, we extract and document every detail.
The grand question. Let’s get back to this a little later. Let’s first walk through some of the latest additions to the collection of graphs on the curl dashboard.
The here data is mostly based on the 167 published curl vulnerabilities to date.
Twenty years ago, we got very few vulnerability reports. The ones we got were only for the most serious problems and lots of the smaller problems were just silently fixed without being considered anything else than bugs.
Over time, security awareness has become more widespread and nowadays many more problems are reported. Because people are more vigilant, more people are looking and problems are now more often considered security problems. In recent years also because we offer monetary rewards.
This development is clearly visible in this new graph showing the severity distribution among all confirmed curl vulnerabilities through time. It starts out with the first report being a critical one, adding only high severity ones for a few years until the first low appears in 2006. Today, we can see that almost half of all reports so far has been graded medium severity. The dates in the X-axis are when the reports were submitted to us.
One of the tricky details with security reports is that they tend to identify a problem that has existed in code already for quite some time. For a really long time even in many cases. How long you may ask? I know I did.
I created a graph to illustrate this data already years ago, but it was a little quirky and hard to figure out. What you learn after a while trying to illustrate data over time as a graph, is sometimes you need to try a few different ways and layouts before it eventually “speaks” to you. This is one of those cases.
For every confirmed vulnerability report we receive, we backtrack and figure out exactly which the first release was that shipped the vulnerability. For the last decades we also identify the exact commit that brought it and of course the exact commit that fixed it. This way, we know the exact age of every vulnerability we ever had.
Hold on to something now, because here comes an information dense graph if there ever was one.
To guide the viewer, there is also a few diagonal lines. They show the release dates of a number of curl versions. I’ll explain below how they help.
Now, look at the graph here and I’ll continue below.
Yes, you are reading it right. If you count the dots above the twenty year line, you realize that no less than twelve of the flaws existed in code that long before found and fixed. Above the fifteen year line is almost too many to even count.
If you check how many dots that are close to the the “4.0” diagonal line, it shows how many bugs that have been found throughout the decades that were introduced in code not long after the initial curl release. The other diagonal lines help us see around which particular versions other bugs were introduced.
The green dotted median line we see bouncing around is drawn where there are exactly as many older reports as there are newer. It has hovered around seven years for several recent years but has fallen down to about six recently. Probably too early to tell if this is indeed a long-term evolution or just a temporary blip.
The average age is even higher, about eight years.
You can spot a cluster of fixed issues in 2016. It remains the year with most number of vulnerabilities reported and fixed in curl: 24. Partly because of a security audit.
A key take-away here is that vulnerabilities linger a long time before found. It means that whatever we change in code today, we cannot see the exact effect on vulnerability frequency until many years into the future. We can’t even know exactly how long time we need to tell for sure.
The older the projects gets, the more we learn about mistakes we did in the past. The more we realize that some of the past releases were quite riddled with vulnerabilities. Something nobody knew back then.
For every release ever made from the first curl release in 1998 we increase a counter for every vulnerability we now know was present. Make it a different color depending on vulnerability severity.
If we lay all this out in a graph, it becomes an interesting “mountain range” style look. In the end of 2013, we shipped a release that contained no less than (what we now know were) 87 security problems.
In this image we can spot that around 2017, the amount of high severity flaws present in the code decreased and they have been almost extinct since 2019. We also see how the two critical flaws thankfully only existed for brief periods.
However. Recalling that the median time for a vulnerability to exist before getting reported is six years, we know that there is a high probability that at least the rightmost 6-10 years of the graph is going to look differently when we redraw this same graph 6-10 years into the future. We simply don’t know how different it will be.
Did we do anything different in the project starting 2017? I have not been able to find any major distinct thing that stands out. We still only had a dozen CI builds but we started fuzzing curl that year. Maybe that is the change that is now visible?
curl is written in C and C is not a memory-safe language. People keep suggesting that we should rewrite it in other languages. In jest and for real. (Spoiler: we won’t rewrite it in any language.)
To get a feel for how much the language itself impacts our set of vulnerabilities, we analyze every flaw and assess if it is likely to have been avoided had we not used C. By manual review. This helps us satisfy our curiosity. Let me be clear that the mistakes are still ours and not because of the language. They are our mistakes that the language did not stop or prevent.
To also get a feel for how or if this mistake rate changes over time, I decided to use the same mountain layout as the previous graph: iterate over all releases and this time count the vulnerabilities they had and instead separate them only between C mistakes and not C mistakes. In the graph the amount of C mistakes is shown in a red-brown nuance.
The dotted line shows the share of the total that is C mistakes, and the Y axis for that is on the right side.
Again, since it takes six years to get half of the reports, we must take at least the rightmost side of the graph as temporary as it will be changed going forward.
The trend looks like we are reducing the share of C bugs though. I don’t think there is anything that suggests that such bugs would be harder to detect than others (quite the opposite actually) so even if we know the graph will change, we can probably say with some certainty that the C mistake rate has indeed been reduced the last six seven years? (See also writing C for curl on how we work consciously on this.)
I think (hope?) we are, even if the graphs are still not reliably showing this. We can come back here in 2030 or so and verify. It would be annoying if we weren’t.
We do much more testing than ever: more test cases, more CI jobs with more build combinations, using more and better analyzer tools. Combined with concerned efforts to make us write better code that helps us reduce mistakes.
