[Daniel's week] April 4, 2025

Daniel Stenberg daniel at haxx.se
Fri Apr 4 18:12:54 CEST 2025


Hello,

We are already at the end of another work week. Things happened.

## https-rr

I wrote up a blog post [1] about the experimental HTTPS RR support in curl to
make people aware of the development want everyone can anticipate from curl in
a future. Or what to play with right now if you're inclined to try out
adventures.

I would love to get more feedback from users who actually try out using
HTTPS-RR.

## release

When the first ever curl release cycle that featured official release
candidates ended this Wednesday we shipped curl 8.13.0 [2].

I believe the old saying that only releases get tested for real still holds
true, as we got a few regressions reported that certainly also existed in the
rc versions. Still, the regressions reported so far have all been relatively
minor and none of them has yet given us a reason to consider doing a patch
release - with is really happy news I think. A testament to the effectiveness
of the release candidates. Let's keep them coming!

## random command lines

One of the things that I have had as a thought in the back of my head for a
long time is to improve the curl fuzzing using the command line tool: fuzzing
the arguments and thus the argument parser etc.

This triggered me into writing a "poor man's fuzzer" script this week. It
figures out all the existing currently supported command line options and then
builds a curl command line using a random amount of them, adding random
arguments where it has to and then it invokes curl and checks what it returns
(using a URL that specifies a port that nothing listens to). There are
actually only four valid exit codes from this, so anything that is not one of
those four is reported as an "anomaly" that fails the test. 267 command line
options and their about 50 short versions (single letter flags).

Boringly enough, it found only a minor documentation issue in the --help
output (which made the parser fail to figure out some options) and after that
it ran flawlessly for a long time. On my machine it can test up to maybe some
200 command lines per second.

Now we have a few CI jobs [3] running this script for a minute in each job to
verify that it does not trigger anything.

## random builds

Having done random command lines testing, Viktor casually mentioned that it
would be a good idea to do something similar for curl builds. Doh, of course!

curl has countless ways of being configured and setup and testing every
combination is impossible. I am under the impression that we typically have
control of doing builds with different third party dependencies present and
missing and even using a few different versions. What instead traditionally
has been reason for past regression is our ability to disable specific
features in the build. And perhaps even certain combinations of features being
disabled.

The current curl configure script has *75* options named --disable- something
that all work independently of each other. The total number of combinations of
these alone is thus 2^75. A big number.

This randomizer was much more successful. Within the first few hours of
playing with it [4], I identified and fixed 6-7 different build problems. This
script invokes curl with a random configure command line, then builds curl and
verifies that it can invoke the result. Each round takes about 10-12 seconds
on my machine. Fortunately, most build problems that happen when a feature is
disabled happen for multiple combinations so it's not like we need to hit that
one in a 2^75 lottery.

I then had the script run for almost twenty-four hours non-stop and it found
no more problems. It is not a guarantee there aren't any more problems lurking
somewhere in the code, but I am fairly confident we cover the basics pretty
good now.

I've decided I will rerun this script at least for a few hours in sync with
future release candidate drops. I have not figured out a decent way to run it
in CI.

## CodeSonar

CodeSonar is one of the commercial static code analyzers we use in the curl
project to find problematic code sections. I get daily updates per email but
the emails stopped coming a while back so this week I contacted them to ask
about it. Turned out to be a glitch. When the system was restored, we got a
smaller avalanche in new findings that I have walked through.

There were some minor actual findings that lead to me tidying up a few
functions. Going forward I expect a smaller amount of news to check out, as it
typically finds something every few days. Most of them false positives these
days.

## VERSIONS

While browsing the curl man page for something I spotted that there was a
mention about a command line option added in a particular version of curl that
I thought looked odd. It looked like it claimed the option was added in a
release that never was made. A quick investigation proved that I was right and
of course than then took my down the rabbit hole of figuring out how many other
wrong version references we have in documentation. The docs/ folder just broke
100,000 lines of text and we have done quite a few releases, so naturally
there are quite a few references.

I decided to add a list of all the 266 past releases to the docs/VERSION.md
document (with their corresponding release dates) [7], and then it was easy to
extend a few of our test cases that check documentation format to also verify
that mentioned version numbers are legit past releases. This of course lead me
to find and be able to fix over half a dozen errors.

The list of past releases might even be a useful resources for other purposes
at some point. Now we just need to remember to add new releases to this list
as otherwise tests will fail and complain about referencing non-existing
releases...

## trurl

We celebrated it is now two years since trurl [6] was born. I haven't done
much work on trurl lately and I have not received much feedback either. All
good to me.

## number of the week

We passed 11,000 closed pull-requests in the curl GitHub repository.

## quote of the week

"it's clear that Stenberg cares deeply about curl. Stenberg and the other
folks maintaining curl are thoughtful, careful, knowledgeable, and dedicated
to the goal of delivering quality software that runs on probably billions of
devices. For free." [5]

## Coming up

- the curl distro meeting 2025 on April 10 [8]

## Links

[1] = https://daniel.haxx.se/blog/2025/03/31/https-rr-in-curl/
[2] = https://daniel.haxx.se/blog/2025/04/02/curl-8-13-0/
[3] = https://github.com/curl/curl/pull/16884
[4] = https://github.com/curl/curl/pull/16962
[5] = https://crankysec.com/blog/go-wrong/
[6] = https://daniel.haxx.se/blog/2023/04/03/introducing-trurl/
[7] = https://github.com/curl/curl/pull/16907
[8] = https://github.com/curl/curl/wiki/curl-distro-discussion-2025

-- 

  / daniel.haxx.se


More information about the daniel mailing list