[Daniel's week] November 14, 2025

Fri Nov 14 16:29:11 CET 2025

Hello friends.

A week can fly by really quick, but when looking back and summarizing it I get 
the feeling it probably was not shorter than other weeks...

## Feature window

Early this week we decided that the few regressions we have seen for curl
8.17.0 are not annoying or important enough to warrant a follow-up patch
release. In my book that is a raving success, as the amount of bugfixes in
that release was unprecedented.

This also makes us able to open the feature window tomorrow Saturday exactly
as planned. We have a number pull-requests queued up ready to merge changes.

We will drop support for Windows CE, VS 2008 and OpenSSL 1.x in this cycle.

## RTMP

This week we found ourselves giving attention to the RTMP situation in curl.
curl does not have a single RTMP test and the library curl depends on for RTMP
decoding, librtmp, does not have a single test either! Combine this with very
few users in the curl camp (2.2% of users according to the latest user survey)
and we see a protocol implementation that is among the weakest in the curl
family of protocols and we have now flagged it for removal next spring [1].
Unless of course someone steps up and addresses some of the problems before
then.

## MQTTS

I casually started working on support for MQTTS for curl. So far we have only
had support for the clear text version MQTT and adding the TLS protected
flavor really isn't that much work.

Oh, and if anyone reading this is an MQTT user: the curl implementation could
really have a polish and fix to make sure it handles sending larger payloads
better. I suppose it has gotten away with the current naive approach so far
mostly because nobody actually sends very big data chunks over MQTT with it.

## 1000 vs 1024

First, there was a bug report saying that curl 8.17.0 made the progress meter
harder to read [2]. That was probably true, because I added an extra digit to
all the size and speed fields, which I thought would be appreciated due to the
added precision. I was wrong. I instead made a follow-up fix that again makes
it only display "raw" bytes up to 5 digits (99999) before it switches to a
unit version, and then it only uses numbers lower than 1000 with a decimal
fraction. Like '123.4k' or '567.8M' etc. Hopefully this makes them more
readable again.

It was then brought up a suggestion [3] that the progress meter should A) not
use 1024-based units but rather 1000-based ones and B) use the appropriate SI
units better explaining the numbers.

To get a feel for how people really think about 1000 vs 1024 I ran a quick
poll on Mastodon [7] only to realize the 1024 version was by far the most
popular answer.

The question about the units display, is it `kB` or `KiB` etc, the reality is
that we use a non-standard single-letter version of the units simply for the
reason that we want to be able to squeeze as much information as possible into
a single line that we don't want to exceed 80 columns. So we use `k` to
actually mean `KiB`, kibibytes: 1024-based, `M` means mebibyte, 1048576 bytes
and so on.

We thus did not do any further changes to the progress meter.

## CVE

Our friends at Aisle Research sent over a series of *thirteen* new findings.
Issues their tools found in curl code that could potentially have security
impacts.

The curl security team jumped on the task starting Sunday and by Tuesday
evening we had fixed 11 of them in git (deemed not security sensible) and one
was eventually found a plain false positive after lots of digging around in
GnuTLS OCSP stapling documentation and source code.

One of their findings however identified a problem with a security impact! We
have registered a CVE for it and we have a security advisory draft. The plan
is to announce it in sync with the pending curl 8.18.0 release. All details
will be made public then.

## IBB

I was contacted by security researcher friend who found an issue in another
open source project covered by the Internet Bug Bounty already back in June.
He had not been able to get any word back from IBB since then and asked me if
I knew anything about it.

This way I was told by appropriate sources that the IBB program had some
management issues over the last few months so it has basically been at a
standstill but I was assured that things are returning back to normal and
that all payouts will be done asap.

## integer parsing

One of the code analyzers we use highlighted for me that we still had a few
places in curl code where atoi() was used. So I made sure to wipe out the last
few instances, created a new graph showing atoi density [5] and then wrote up
a small blog post [6].

## strict torture

This week I have experimented with a new way to detect spots in the curl
source code where ignore fatal errors instead of exiting and returning error.

Since decades we have the "torture tests" in curl. It is a set of wrapper
functions for fallible system functions (like all the memory allocating
functions). In this mode, we run a test case, count the number of fallible
function calls that were done and then we re-run that test case over and over
that many times and one by one we let the next function return error. When
doing this, curl should never crash or leak memory. We run these tests as part
of the CI builds and they are truly great.

This week, I have made a "strict torture mode" which takes this method a
little further: now, after curl has exited because of an injected error, my
script checks if there is any additional memory allocation done *after* the
failed memory allocation and if so that signals a possible error. This,
because after failing to allocate memory there is almost never a good idea to
continue. In fact, in most cases it is downright wrong. This new mode helped
me detect several such code sequences in curl code and I have thus been
cleaning them up.

The challenging part with this setup is that due to internal APIs and some
deliberate design decisions, not *all* these occurrences are bugs. I have not
yet been able to actually run this check in CI because I have not managed to
do it completely safe from false-positives - and I need to figure out a way
how to do code mark-up for allocations that are allowed to fail this way.
Also, I'm sure I have yet found all the mistakes we should fix.

## FOSDEM talk

Earlier this week I ran on poll on Mastodon [4] about which title to use for
my FOSDEM 2026 talk proposal thinking I have plenty of time to prepare, and
then only this morning I was reminded that the cut-off date for proposing
talks to the main track is actually already this Sunday. So I stopped the
procrastinating and instead proceeded and submitted my proposal. Let's see if
they want it.

## Polhem Prize

This coming week I will again attend the annual Polhem Prize award [8]
ceremony. A tradition I started when I got the award myself back in 2017 [9].

## Coming up

- Saturday: the curl feature window opens
- Thursday: meeting with another AI code analyzer company

## Links

[1] = https://curl.se/dev/deprecate.html
[2] = https://github.com/curl/curl/issues/19431
[3] = https://github.com/curl/curl/issues/19448
[4] = https://mastodon.social/@bagder/115541558916337327
[5] = https://curl.se/dashboard1.html#atoi-density
[6] = https://daniel.haxx.se/blog/2025/11/13/parsing-integers-in-c/
[7] = https://mastodon.social/@bagder/115535765105053532
[8] = https://en.wikipedia.org/wiki/Polhem_Prize
[9] = https://daniel.haxx.se/blog/2017/10/20/my-night-at-the-museum/

-- 

  / daniel.haxx.se