[Daniel's week] March 28, 2025

[Daniel Stenberg]

# March 28, 2025

Hello, yeah there was no email last week but I'm back now.

## vacation

I had the most refreshing week off.

## reverted the response space

In my previous email I mentioned how I modified the HTTP/1 response parser to
follow the spec more strictly (and require a single space after the three
digit response code). I had to give up that stance and declare defeat quite
soon after that, as a number of projects started to report that they ran into
problems with that. That was probably also just a small tip of the iceberg.

I made the parser more laxed again and calm has returned.

## rc2 / rc3

I shipped curl 8.13.0 rc2 while on vacation and I made rc3 this week. rc2 was
reported to have a few regression that I hope we have fixed in rc3. I don't
believe I have seen any reports on rc3 yet, even 48 hours after upload, so
things seem to go in the right direction.

I also improved the website experience for how release candidates are listed
on the rc page and it now also displays the exact commit hash the build was
made from.

## mbedTLS CVE

This week mbmedTLS 3.6.3 was announced [1]. The new release of this TLS
library was found by the rennovate bot which submitted PR for the curl CI job
that uses mbedTLS, like it always does for new releases.

As I checked out the PR details, I glanced over the release notes and one of
the newly reported security vulnerabilities mentioned in there sounded
familiar. It turns out that CVE-2025-27809 [3] is indeed the very problem I
reported [2] to the mbedTLS project back in April 2016, almost nine years ago!

I was just a little disappointed that they originally did not credit me at
all. Once I complained, they subsequentially fixed that.

As you can see, the issue was closed within a week without anyone seemingly
understanding the issue or trying to address it back then. I don't know how it
came that they suddenly realized their mistakes and fixed it, all this time
later.

## normalizing URLs

We received a bug report [6] that identified a discrepancy between the
curl_url_get() functions's behavior compared to how it is documented to work:
it is said to return the full URL "normalized" but given a few test inputs it
was clearly not.

Normalizing in this context would imply that curl would try its best to return
a single consistent version of URLs even when given variations to for example
help applications to compare two separate URLs. It is not as straight-forward
as it may initialize sound: the simplest and most naive approach would simply
decode and then reencode every single URL component independently and then put
them all together into a URL again.

This does however not work. The most obvious example is '=' vs the hex encoded
version of it (%3D) and '&' vs %26 in the query part. Server side parsers
often split the query string into a sequence of name=value pairs, separated by
amperands. That makes them treat the plain version vs the encoded version
differently. The same goes for slashes vs %2f in the path part etc.
Normalizing URLs is a mine field.

I filed an initial PR for this [7] and after having polled for feedback [8] I
was made aware of problem in another project that occured because of URL
normalizing [10] which made it clear to me that we definately need to provide
a way for users to switch it off on demand. Or possibly make make it opt-in?

## HTTP/3 talk

I did another talk about HTTP/3 this week here in Stockholm for a local user
group at a closed event. It went really well - it is almost like I have talked
about this so many times now I feel pretty confident.

It's good to get out in the real world and talk to people and developers every
once in a while to get to see what they do and learn about the struggles and
challenges they face.

## curl up

We opened up for registrations to curl up 2025 in Prague in May. Head over to
the main curl up page [9] to find the registration link.

Attending the event is entirely free but registration is mandatory so that we
know how many people to plan for.

We want broad participation rather than just a few people from the inner
circle. If your company wants to sponsor the event and get visiblity in this
cool context, come talk to me.

The list of proposed subjects to talk about at the event is also slowly
growing (listed on the curl up page), and it looks like we will have another
fun and interesting curl up this year.

## less base64

In the xz attack of last year [4], we learned that having opaque bundles of
data in the git repository could be used to store malicious payloads.

We have since then worked on reducing "blobs" in the curl git repository to
make it easier to review and scrutinize every stored byte. We also have had a
CI job that scans for "binary files" to make sure we don't accidentally add
new ones.

This week we took a huge leap to increased transparency: first I erased all
use of base64 encoded blobs in test cases. Some of them still feature
sequences of binary bytes encoded in the test system's hex formatting syntax,
but they are now more apparent and I made sure to shrink them. It is difficult
to remove them completely.

As a second step Viktor Szakats removed the pre-generated certificates from
the repository that were used for tests. They are now instead generated at
runtime. This removed the last files in the repository with binary content and
the last somewhat large base64 encoded blobs. In the name of transparency and
increased ability for everyone to inspect and understand what is stored.

## porting

Because I was asked about how to port libcurl to a new RTOS, I started writing
a new document for exactly this purpose [5].

## Coming up

- Monday: the monthly "You can help us" email on the libcurl mailing list
- Wednesday: curl 8.13.0 release
- Wednesday: the curl release video live-stream on Twitch

## Links

[1] = https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.3
[2] = https://github.com/Mbed-TLS/mbedtls/issues/466
[3] = https://github.com/advisories/GHSA-76fv-m4gp-q47j
[4] = https://en.wikipedia.org/wiki/XZ_Utils_backdoor
[5] = https://github.com/curl/curl/pull/16860
[6] = https://github.com/curl/curl/issues/16829
[7] = https://github.com/curl/curl/pull/16841
[8] = https://curl.se/mail/lib-2025-03/0029.html
[9] = https://github.com/curl/curl-up/wiki/2025
[10] = https://issues.apache.org/jira/browse/CXF-7931

-- 

  / daniel.haxx.se || https://rock-solid.curl.dev