[Daniel's week] January 16, 2026

[Daniel Stenberg]

Hi friends.

Allow me to share some of the things that kept me occupied me this week!

## bug-bounty and hackerone

We started out the week receiving seven Hackerone issues within a sixteen hour
period. Some of them were true and proper bugs, and taking care of this lot
took a good while. Eventually we concluded that none of them identified a
vulnerability and we now count twenty submissions done already in 2026.

We made some noise as I mentioned my PR in progress [1] that is about to
remove all mentioned of a bug-bounty from the curl documentation. It is still
in the planning phase and there will be more communication done about it, but
we aim at shutting this down by the end of January 2026.

The main goal with shutting down the bounty is to remove the incentive for
people to submit crap and non-well researched reports to us. AI generated or
not. The current torrent of submissions put a high load on the curl security
team and this is an attempt to reduce the noise.

We believe, hope really, that we still will get actual security
vulnerabilities reported to us even if we do not pay for them. The future will
tell.

## exposing silly

This week I had a lengthy discussion with a person who did one of the silly AI
generated submissions on Hackerone and whom I have publicly ridiculed because
of this.

It was useful for me to make me remember that oftentimes these people are just
ordinary mislead humans and they might actually learn from this and perhaps
even change.

In this particular case, the person insists I have "ruined their professional
life" because of my language and my exposing the (link to the) issue on
Mastodon. I think that is overdoing it as I don't know the persons real name,
location, language, sex or even continent. All we know is a hacker alias once
used in a report. And since there have been so many silly ones, you cannot
even tell which of the many users I speak of here...

This is a balance of course, but I also continue to believe that exposing,
discussing and ridiculing the ones who waste our time is one of the better
ways to get the message through: you should NEVER report a bug or a
vulnerability unless you actually understand it - and can reproduce it. If you
still do, I believe I am in the right to make fun of - and be angry at - the
person doing it.

But sure, I also need to be restrained. The person might be a teenage kid who
did a single one-time mistake and will then move on in life and make excellent
stuff in the future.

Leaving Hackerone it might be harder to publicly disclose silly reports, but I
need to work out a system so that I can keep showing off the worst offenders.

## asking me

Recently I have been getting quite a lot of private emails from random persons
out in the world who wants my advice or opinions on things they do or want to
do. From reviewing their apps to career advice and more. It is humbling and
of course an honor to get asked and be thought of as a person to have good
opinions and guidance in these matters, but also challenging.

In order to answer these emails in a good and responsible way it requires that
I get a lot more information and that there's a communication and discussion
really rather than me just decreeing some quick platitudes. Unfortunately that
makes me hesitate, as I would need more time to do a proper response and
that's where it usually breaks for me. When I have to spend time to do it, it
becomes an agenda item that sits a few notches down in an ever-growing list of
things to do and I then typically never actually get to that item in a timely
fashion and then suddenly weeks have gone by and then I give up and just
archive the email... Sorry.

## rate limiting

Stefan Eissing has continued the work on rate-limiting in curl [2]. It has
been a rather long-standing series of back and forth with different attempts
and generations of code.

The core of the issue is that libcurl offers a feature for rate limiting: when
doing a transfer, do not transfer more than a specified amount of bytes per
second - and do it with a sufficient precision and make it work even when doing
parallel transfers and across all the different protocols and versions. This
is somewhat easier said than done.

We have had a long-going discussion since a change a while back modified the
rate-limiting to become much more precise to the joy of some users - which
simultaneously had the downside that it then used more CPU, which was not
appreciated by some other users. The holy grail of rate-limiting has since been
to find the golden middle way: sufficiently precise in a way that does not use
"too much" CPU.

## features

As we have not received any reports about regressions in curl 8.18.0, we are
going to open the feature window tomorrow and merge new things. There are a
few things in the pipe that I know will happen:

- removal of OpenSSL-QUIC support
- removal of Windows XP support
- adding support for fractions to curl's --limit-rate and --max-filesize
   options to allow users to say 2.5 megabyte or 3.2 gigabyte

## DNS and curl

On Thursday evening I had a talk/conversation with 70+ engineers at ICANN
about "DNS and curl". Fun!

## #ifdefs

As we were fiddling with #ifdefs in a current PR (as we so often do) it struck
me that it would actually be interesting to know how we trend in various #if
conditional use in curl source code. I mean ideally we would reduce the amount
over time when we try to simplify.

I pasted my version first [3], but I also found some minor mistakes so the one
that is going up on the dashboard [4] starting tomorrow will me subtly
different and more correct.

Turns out we do about 20-25 C preprocessor conditions per 1000 lines of code
pretty stable. There might be a tiny long-term trend that the density going
down, but if so it is not by much.

## Coming up

- end of curl feature freeze
- work on my FOSDEM talk

## Links

[1] = https://github.com/curl/curl/pull/20312
[2] = https://github.com/curl/curl/pull/20228
[3] = https://mastodon.social/@bagder/115905029399882496
[4] = https://curl.se/dashboard.html

-- 

  / daniel.haxx.se