[Daniel's week] May 27, 2023

[Daniel Stenberg]

Hello,

Another packed week passed.

## c-ares 1.19.1

I kicked off this week by putting together and uploading this brand new c-ares
release [2] on the Monday. This follows a security audit done by x41 [1] that
unveiled three problems, and then there was a fourth issue reported
separately. I did not do a lot more for this than pressing the keys to make
the actual release happen.

## curl 8.1.1

I spent Tuesday putting together a patch release [8] due to the rather 
annoying regressions we shipped in the previous release. We manage to cram in 
quite a lot of bugfixes in the mere six days that elapsed since the previous 
release. By our updated policy, we should make patch releases a little easier 
than in the past.

## another patch release pending

It did not take long until we realized that even curl 8.1.1 shipped with some
problems that put obstacles in the way for users and we have thus decided to
ship yet another patch release next week. Due to that, we also postpone the
opening of the feature window - with the intent to still keep planned 8.2.0
release date. Let's see next week if we deem that is actually still possible.
curl 8.1.2 is now planned [9] to ship on Tuesday May 30.

## Polhemsrådet

When the Polhem Prize website was updated this week, I could also announce
that I have accepted and joined one of the "councils" [3] for this award that
helps appoint the winner each year. I consider it an honor and a pleasure.

## libssh2 release

I presented a proposal [4] in the libssh2 project to (finally) make a new
release next week. Unless some of the key active maintainers speak up against
it before then, I hope to do that on Tuesday 30. The same day the next curl
release is also set to happen. Double release fun!

## Multiple Cookie: headers

In my report last week I missed to mention by issue I brought to the HTTP WG 
as I discovered a case of two RFC contradicting each other [5] regarding HTTP 
clients' use of Cookie: headers. Should it only be one header or can it be 
more?

I am asking that the pending cookie RFC update clarifies the situation. I 
think we know the answer, but it would help to make the spec clearer: it 
should only be one in HTTP/1, but when sent over HTTP/2 or HTTP/3 they can be 
sent as multiple headers, which in fact can be beneficial for compression 
reasons.

## curl talk

On Thursday I visited friends at the company CAG [6] in Stockholm, a company
where I used to work up until mid 2009, and did a curl talk. Lots of fun. Lots
of positive feedback. And I handed out many curl stickers.

## security reports flood

This week for some reason we had a mini explosion in number of security
reports submitted to us via hackerone [7]. But also a flood of bogus and not
very well researched issues so not a single one of the almost a dozen reported
issues has actually been proven a valid in-scope issue.

One issue did point out a valid bug in the website (that I fixed immediately)
but the website is out of scope for our bug bounty.

## user survey

For the tenth consecutive year, we put together a curl user survey [10] and we 
ask everyone we know and can reach who ever used curl or library within the 
last year, to donate a few minutes of their precious time and give us their 
honest opinions. We don't have any analytics or telemetry for any of the 
products. The only way we can get info about what is good and what is bad, 
what is used and what is not used, is to ask users. And since we don't know 
who our users are either, we ask openly and hope that as many as possible 
respond.

## C mistakes

One of the topics that often seem to attract attention and cause discussions
to flourish is when I bring up statistics about past curl vulnerabilities.
Today, I created a new graph [12] for the curl dashboard [11] that shows how
large share of all the vulnerabilities that have been "C mistakes" per date of
the reports. It does not care about nor show when the flaws were introduced,
only when they were reported to the project.

It shows that over the last three-four years or so, the C mistake share has
been shrinking from 55% down to 42% of all reported vulnerabilities. I added
this as a regular dashboard graph now to allows to keep monitoring this
development as we go further. Will it continue to shrink?

I should add that I manually inspect all security vulnerabilities and judge if
I think the mistake is one that likely would not have been made if we had not
used C, or if it would have been done anyway. It can be a matter of opinion in
some cases, but mostly it really is not.

## Coming up

- libssh2 release
- curl release
- Fossified podcast episode recording

## Links

[1] = https://www.x41-dsec.de/news/2023/05/25/c-ares/
[2] = https://c-ares.org/changelog.html
[3] = https://daniel.haxx.se/blog/2023/05/24/polhemsradet/
[4] = https://github.com/libssh2/libssh2/issues/790#issuecomment-1557680640
[5] = https://github.com/httpwg/http-extensions/issues/2541
[6] = https://www.cag.se/
[7] = https://hackerone.com/curl
[8] = https://daniel.haxx.se/blog/2023/05/23/curl-8-1-1-lets-do-this/
[9] = https://github.com/curl/curl/discussions/11209
[10] = https://daniel.haxx.se/blog/2023/05/24/curl-user-survey-2023/
[11] = https://curl.se/dashboard.html
[12] = https://mastodon.social/@bagder/110434979647837666

-- 

  / daniel.haxx.se