[Daniel's week] May 9, 2025

Fri May 9 17:52:31 CEST 2025

Hello friends,

Lots of things happened. Again.

## All this in real-time

I just want to remind you dear reader that most things I work on, and most of
the stuff I write about in these weekly emails, can also be seen unveiled in
real-time by following me on Mastodon [14] or the mirrored version on Bluesky
[15]. I have a "real" account on Bluesky as well [16] but I rarely post with
it.

## curl up

Because of the national holiday combined with the curl up weekend I simply did
not manage to produce a weekly email last week. This week's edition thus
contains some blurbs that actually happened already a week ago. I trust that
is okay.

curl up 2025 [1] took place in Prague over the weekend. We do these events on
weekends due to a vote we had a few years ago that made it clear that many
people have a hard time to attend on work hours. A bit sad situation, but we
adapt to reality.

I landed in a very hot Prague (the app reported 27C) that was packed with
tourists. We gathered in a lovely and casual room where we talked curl details
intensely the entire weekend. I wrote about a blog post [12] about it, and
there are no less than fourteen videos recorded and uploaded from it.

I did six presentations myself, with a total of almost two hundred slides.

Unfortunately we had some technical difficulties that made the first two
recordings so bad I decided we don't share those. The main source of the
difficulties was the fact that my webcam simply could not record the projector
screen without color flickers because of too fast shutter speeds and it took a
while until we got a second camera with more adjustable options prepared.

Next time, we should probably record the slides directly from HDMI instead of
going via a camera and instead use a camera only for the presenter. I also
finally decided that my laptop needs to be updated for the next time so that
it can do a better job at streaming + recording. Some "hiccups" this time was
clearly due to it just being a bit sluggish. You'd think streaming and saving
1080p with two different camera inputs shouldn't be that tough job, but this
laptop is eight years old and it was not a very fast one even when it was new.

## curlinfo

Last week I introduced this new tool in the curl build: curlinfo. It it is a
tool that is built with the sole purpose of outputting information about
features that are enabled/disabled in the build. This tool was previously
called "disabled" and lived in the test directory, but it has now been
improved and moved in the directory hierarchy. The tool is not meant to be
installed or used outside of a curl build: it basically helps the test suite
know better what to expect and what tests that can and cannot run.

One of the things it does, which we previously could not do, is to tell the
test suite if the curl build is able to "override DNS" so that we can run
tests that need the custom DNS server to run and get used. See my mentions
about the test DNS server in previous weeks.

## tpm2

After many hours of struggles and debugging, we finally reach success and I
could merge some work into curl that makes it work with OpenSSL "providers"
correctly. Or rather, I hope it works proper in a generic way as I made one
specific tpm2 provider setup work and it *should* mean that the general case
works as well. It's code that is next to impossible to write test cases for.

The provider API in OpenSSL is ridiculously under-documented and there are no
examples. What finally made me able to work it out was by single-stepping
through the code with gdb. Of course, I also ended up doing the cleanups in the
wrong order which caused OpenSSL to do a heap-use-after-free! I reported this
[13]. They say it can't be fixed, only documented.

## rc1

I shipped curl-8.14.0-rc1 and announced feature freeze a day early so that I
could focus on curl up stuff. So far not a single regression has been reported
about it which is either good news, or perhaps nobody is actually testing it.

This was also the first release candidate to use the new git tag scheme we
have decided to use for rc builds to make it easier for git users to know
exactly what is in them.

## AI craziness

Again. Remember I blogged about it [10] already in early 2024?

When the 6th AI slop security report of 2025 landed in our HackerOne inbox
this weekend I felt that enough is enough. I wrote about it on Mastodon and
what particularly made people see me was my LinkedIn post [2] that really
exploded. Possibly one my most shared/liked/spread social media posts of all
times. LinkedIn claims 512,000 impressions.

Hacker news [3]. heise.de [7]. Ars Technica [4], The Register [6], Low Level
on YouTube [5], itsfoss [8], OSnews [9] and many more picked it up.

Of course the issue is not actually about AI, but rather that it is such a low
effort action to submit issues that require such a big effort to dismiss.

I am in communication with HackerOne. They take it seriously and say they are
working on improving things from their end.

Some stats from the security reports submitted to curl in 2025:

curl has received 32 security vulnerability reports.

Out of those, two were confirmed genuine vulnerabilities. The latest one
submitted January 23.

Six of them (almost 20%) were AI slop (some of the others might as well be,
but it isn't always easy to tell).

Ten of them we classified as "normal bugs" and took care of the normal way.

As a general rule, we spend several man hours on every incident but we don't
actually track nor measure that.

## curlx

Over twenty years ago we realized that we have code in libcurl that would be
convenient to reuse in the curl tool, but if the code is not reachable via the
public API there is no proper way to do it.

During the early project years we added several "irrelevant" (not transfer
oriented) functions to the API for this purpose but we soon learned that it is
the wrong way. Adding irrelevant functions adds to the "attack surface", adds
to the maintenance burden and generally just increases the work load.

In order to share code between the library and the command line tool, we
introduced the internal concept of "curlx" functions. Functions using a curlx_
prefix that can be compiled outside of libcurl, for the tool's purposes. This
way, we could avoid code duplication, avoid cluttering the API, not add to
the ABI complexity and still get code reuse. Over time these functions also got
used in the test suite.

This concept has worked rather fine since 2004. It has grown and over time it
however became a little complicated, fragile and messy in the code.

At curl up 2025 we discussed converting the curlx functions into a internal
library of its own [11], but we landed the simpler/better take: just split
them off properly into their own sub directory and make sure they all are used
with the curlx_ prefix unconditionally. This makes it clearer to everyone who
reads and writes curl code and should help us identify exactly when such
functions are used and also even how the build for them works.

Inspired by the weekend discussions I immediately took it upon myself to push
this forward and during this week I have landed a series of pull requests that
have cleaned up things considerably. The work also helped highlight a few
areas with questionable past decisions that we now can work on cleaning up.

## meta hash

Followers of the git activity in curl should have noticed quite some activity
the past few weeks spearheaded by Stefan that converts a bunch of code using
pointers to protocol specific data structures into a new design that is using
a hash-based system instead with fixed hash strings for the different
protocols.

This helps us clean up better and more consistently. It helps us
compartmentalize protocol implementations better and move protocol specific
code and knowledge into the protocol specific files. And of course it has
allowed us to remove some rather ugly-looking (and error-prone) use of unions
with different pointer types that depend on what protocol the structs are
setup to use.

## Coming up

- 8.14.0-rc2 ships on Monday
- time to do another trurl release

## Links

[1] = https://github.com/curl/curl-up/wiki/2025
[2] = https://www.linkedin.com/posts/danielstenberg_hackerone-curl-activity-7324820893862363136-glb1
[3] = https://news.ycombinator.com/item?id=43907376
[4] = https://arstechnica.com/gadgets/2025/05/open-source-project-curl-is-sick-of-users-submitting-ai-slop-vulnerabilities/
[5] = https://youtu.be/xy-u1evNmVo?si=R-cgmwRmKomc4ZWd
[6] = https://www.theregister.com/2025/05/07/curl_ai_bug_reports/
[7] = https://www.heise.de/news/cURL-Maintainer-Habe-die-Nase-voll-wegen-KI-Bug-Reports-10372739.html?wt_mc=sm.red.ho.mastodon.mastodon.md_beitraege.md_beitraege&utm_source=mastodon
[8] = https://news.itsfoss.com/curl-ai-slop/
[9] = https://www.osnews.com/story/142300/curl-bans-ai-security-reports-as-zuckberg-claims-well-all-have-more-ai-friends-than-real-ones/
[10] = https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/
[11] = https://youtu.be/5ZB8_IGM3YU?si=THE9IiCWcM3EtsUz
[12] = https://daniel.haxx.se/blog/2025/05/06/curl-up-2025-is-over/
[13] = https://github.com/openssl/openssl/issues/27522
[14] = https://mastodon.social/@bagder
[15] = https://bsky.app/profile/bagder.mastodon.social.ap.brid.gy
[16] = https://bsky.app/profile/daniel.haxx.se

-- 

  / daniel.haxx.se