[Daniel's week] July 3, 2026

[Daniel Stenberg]

# July 3, 2026

No weekly emails from me over the next two weeks.

## post-release

We have seen a few minor regressions reported for curl 8.21.0 but none of them 
reached the level of criticality we feel we need in order to make a patch 
release. The pre-releases are really fulfilling their purpose and now it is 
over a year since we last did a patch release.

Based on this, we will open the feature window tomorrow. We keep the window 
open for two extra weeks this time because of the summer of bliss which 
coincides with this and during which several curl maintainers will be slower 
than usual. The bliss is also the reason for us pushing the release date 
forward in time by two weeks making this a ten week release cycle instead of 
the standard eight weeks.

## bliss

We received and confirmed one vulnerability report before the summer of bliss 
started, so there is already one severity low CVE in our queue, waiting to get 
published in sync with the 8.22.0 release.

As I write this, the bliss is only in its third day but it feels relaxing 
already. To not have that constant nagging feeling with incoming 
vulnerabilities waiting in the queue to get managed is awesome.I can already 
sense that this is going to be a really good thing for us. A proper vacation.

The original report with 35 findings after the Mythos curl scan back in May is 
now public in a GitHub gist [3]. I figure it might be somewhat interesting to 
those interested in how such a report can look like. As I said already before: 
I did not run the scan myself so I cannot share details about the actual 
process of running it, or which prompts to use etc. All the issues in the 
report have been addressed one way or another.

Just before the bliss started, I posted a blogpost about how to do good 
vulnerability reports [9]. Maybe it helps someone.

## graphs

Two years ago I created this graph that shows the number of known 
vulnerabilities in curl code per every 1,000 lines of code [4]. I like to call 
it the vulnerability density. This week I improved this graph so that instead 
of counting all vulnerabilities as equal, it now shows them separated into 
which severity levels they have. This way we can see that recent code has more 
low and medium vulnerabilities, while back in the early days they were more 
severe. Of course the slope of the curve going down to zero in the most recent 
release down right is more a result of how it takes time to find problems 
rather than implying that we are bugfree now. As we go forward into the 
future, reporters will find problems also in the release we shipped last week 
which right now has no public vulnerabilities.

When reporters find security problems in curl, they tend to be old at the time 
they are found. The average age of curl vulnerability is over eight years and 
the median age is over six years. To help illustrate this in the graph, I 
figured out how to add two arrows into the image that shows at what dates in 
the past that mark the average and median ages of vulnerabilities. It might 
indicate something.

I also created a new graph for the curl dashboard, the 114th, which shows how 
many authors in the git repository it takes to reach X% of the total commit 
share, accumulated over all time [5]. It shows an interesting peak in 2025, 
implying that the top authors have actually increased their activities 
compared to the rest since then. 23 developers authored 90% of all commits so 
far. 4 authors wrote 70% of all commits.

Also, I finally realized exactly how the xtics is supposed to be set with 
gnuplot to properly show the years on the x axis as I want them. The former 
approach I used was a little hacky and sometimes made the output render 
wrongly. “set xtics time 1 years” is the way.

## website

The curl.se website traffic volume reached 2.75 TB/day, which takes it above 
one petabyte per year rate for the first time ever. At the same time, over the 
last 28 days, curl.se links have appeared in 3.83 million google search 
results.

In a conversation with a customer the other day, I realized that the pages on 
the website that lists all the vulnerabilities a single curl release includes 
was missing some key details. For example this for 8.20.0 [6]. Starting now, 
this list also includes severity levels and CVE identifiers. Makes the list 
more similar to the one on the main CVE list page [7].

## NTLM removal

The Azure Devops blog posted an article related to the pending removal of NTLM 
support from libcurl and therefore also from git [1].

## wcurl is two years old

Exactly two years ago Samuel Henrique announced the first version wcurl 
version [8].

## Coming up

- The feature window opens tomorrow

- I will go on proper vacation next week, no weekly email for the next two weeks

- On July 14-16 I will attend the 7th HTTP workshop 2026 in Basel, Switzerland

## Links

[1] = https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/
[2] = https://daniel.haxx.se/blog/2024/07/03/wcurl-is-here/
[3] = https://gist.github.com/bagder/c9b83a19f30e82e41b11f6315465b17a
[4] = https://curl.se/dashboard1.html#vulnerabilities-per-kloc
[5] = https://curl.se/dashboard1.html#author-share-of-all-commits
[6] = https://curl.se/docs/vuln-8.20.0.html
[7] = https://curl.se/docs/security.html
[8] = https://daniel.haxx.se/blog/2024/07/03/wcurl-is-here/
[9] = https://daniel.haxx.se/blog/2026/06/29/do-excellent-vulnerability-reports/

-- 

  / daniel.haxx.se