From daniel at haxx.se Fri Dec 1 23:37:04 2023 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 1 Dec 2023 23:37:04 +0100 (CET) Subject: [Daniel's week] December 1, 2023 Message-ID: <875so991-909q-3190-9s0-q5o84orpno3@unkk.fr> Hello friends, Another week passed. ## release prep I'm lining up the ducks this week and getting myself and curl ready for the 8.5.0 release next week. We've received a fair amount of snow over the last week so when the sun was out I took the opportunity and took my "release image" for the release in the snow [7] with my wooden tiles in the same spirit as recent releases. We have two pending security advisories and I pre-notified the distros mailing list about them both this week. We have given them severity level medium and low, and I don't think they will cause much panic when you all get to learn about the specifics on Wednesday. Otherwise, the prepping is mostly about slowly fix bugs and merge bugfixes while working on the release blog post and the corresponding slides for the release presentation. ## c-ares Brad House has continued to work on c-ares stuff like a madman so this week we shipped c-ares 1.23.0 [1] with more features and of course a range of bugfixes. Brad says chances are his recent speed uptake might slow down a bit again going forward. ## xCurl I got an email from someone asking about details around xCurl. I had no idea what it was, but now I do and I blogged about it [2]. tldr: it's a Microsoft game development kit based on the libcurl API, built on a old libcurl version with a lot of custom patches applied from them. ## hacked into devices I got another email from what sounds to be from someone with maybe a mental problem or something and I blogged about that [3] too. She starts out accusing me of having "hacked into" her devices and then goes into a long side-track about ... yeah, I'm not really sure. ## symbols I made sure all libcurl symbols (defines, enums and typdefs) are presented on the curl site properly sorted by name [4] or by version the were introduced in [5], complete with links to where they belong. ## OpenSSL After OpenSSL's 3.2 release last week several people have asked about curl's plans for supporting HTTP/3 using their QUIC implementation. I answered one of them in a multi-paragraph response here [6], but the gist is that no one has started that work and it is not considered "easy". Hopefully we can find someone to sponsor this work so we can have someone spend proper time and energy to get it going. ## Coming up - curl 8.5.0 on Wednesday, including video release presentation live-streamed ## Links [1] = https://c-ares.org/ [2] = https://daniel.haxx.se/blog/2023/11/30/xcurl/ [3] = https://daniel.haxx.se/blog/2023/11/26/you-have-hacked-into-my-devices/ [4] = https://curl.se/libcurl/c/symbols-by-name.html [5] = https://curl.se/libcurl/c/symbols-in-versions.html [6] = https://github.com/curl/curl/discussions/12425 [7] = https://mastodon.social/@bagder/111493924165391163 -- / daniel.haxx.se From daniel at haxx.se Fri Dec 8 16:58:26 2023 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 8 Dec 2023 16:58:26 +0100 (CET) Subject: [Daniel's week] December 8, 2023 Message-ID: <36426orr-335o-n5so-34so-o5s349r415o@unkk.fr> Hello, Friday meens another weekly summary! ## release I followed the release checklist carefully and shipped curl 8.5.0 [8] on Wednesday morning exactly as planned. I shared the details for the new vulnerabilities and I did the release video live-stream. The stream turned out a little different than usual because obs studio decided to crash on me instantly when I try to share a window, so I had to rearrange it a little and instead share a full screen to work around the issue and still be able to present something. Something I need to get fixed in time for the next stream I guess because this was not ideal. The release was not the best one this time either as we got an early bugreport [2] that showed that the release tarballs lack a file - a script really - that makes a recently create test case always fail. We of course will check why this CI builds missed this and we have fixed the problem in git. It has not yet been decided if this is enough to warrant a patch release but my gut feeling says no. If there are not worse problems reported within the coming week I think we can live with this and rather aim for a full release cycle until we ship. The scheduled next release date is January 31, 2024. ## CVEs The two security vulnerabilities we announced this time were both fairly harmless. Both Hakerone reports have been disclosed so that you can check out our work, communication and process from the very first report to us until we published them. See CVE-2023-46219: HSTS long file name clears contents [3] and CVE-2023-46218: cookie mixed case PSL bypass [4]. Neither of these problems is what I categorize as a "C problem" (a mistake that likely would not have happened if we would use a memory-safe language). We are now at a total of 150 reported CVEs through the project history. Just over 40% of them are due to C mistakes. The share of C mistakes among the reported vulnerabilities in curl has in fact been shrinking continuously since its peak in 2019 [5]. Note that this graph is per the *report date*. If we instead check the graph that is based on the date where the flaw was *introduced* [6], we can see that the share of C mistakes present in the code has actually never been above 50% of the total. Of course, if we would limit the data to only high or critical vulnerabilities, we might see a different story. I will probably enjoy myself by making some new graphs for that purpose soon. ## cpy and alloc calls Classic buffer overflow mistakes in C code usually involve using one of the functions memcpy, strcpy or strncpy - the `*cpy` calls. In curl, we have over time introduced many helper functions that make the need for using such cpy functions less prevelant. An idea being that it might also then over time make the code better and hard to do buffer mistakes with. This week I merged a new round of code cleanups where I found corners of the source code where we could clean up code paths and reduce the number of such cpy calls [7]. Right now in git master, the lib/ directory tree has 260 matches for '(mem|str|strn)cpy', out of 137,773 lines of code (including comments). One cpy call for every 529 lines of code. Some quick history checks for the same stuff: - In 7.81.0 we had 299 cpy calls in 125,694 lines of code: one cpy call for every 420 lines of code. - In 7.69.1 we had 288 cpy calls in 116,551 lines of code: one cpy call for every 404 lines of code. - In 7.52.1 we had 234 cpy calls in 98,341 lines of code: one cpy call for every 420 lines of code. Another common area of mistakes in C code is related to allocating memory and using (temporary) heap buffers. In particular everything that has to do with realloc(). We therefore work on reducing such calls as well - and instead use common helper functions. Right now in git master, the lib/ directory has 297 matches for '(m|re|c)alloc\('. One alloc call per 463 lines of code. - 7.81.0: one per 409 lines of code - 7.69.1: one per 377 lines of code - 7.52.1: one per 362 lines of code ## audit We have another curl code audit coming up. It is again sponsored and organized via OSTIF and this time the focus is on and limited to curl's HTTP/3 components. The scope is what the OSTIF sponsor (who still is unknown to me) has asked for and I think it seems suitably timely since we just this week shipped the first curl release ever with HTTP/3 support no longer being just experimental. As you might recall, curl supports HTTP/3 using one out of (currently) three different backends but only the ngtcp2+nghttp3 backend is considered non-experimental so far. Those two libraries only just recently left their beta phases, in which they have been for several years. I have no doubts that there might be details to find and possible issues to address in this area, perhaps in particular in the interactions between the multiple libraries and in how they are used and not used etc. Perhaps also because HTTP/3 has not been used much in production with curl up until now so there is likely to still exist a few rough corners we better polish off. This audit is going to be performed by Trail of Bits. The same company who did our previous code audit, published at the end of 2022. Links to their previous audit reports from then cam be found on the curl security page[1]. The audit kick-off meeting happens today. ## Coming up - the HTTP/3 code audit ## Links [1] = https://curl.se/docs/security.html [2] = https://github.com/curl/curl/issues/12462 [3] = https://hackerone.com/reports/2236133 [4] = https://hackerone.com/reports/2212193 [5] = https://curl.se/dashboard1.html#c-reports [6] = https://curl.se/dashboard1.html#c-vulns [7] = https://github.com/curl/curl/pull/12453 [8] = https://daniel.haxx.se/blog/2023/12/06/curl-8-5-0/ -- / daniel.haxx.se From daniel at haxx.se Fri Dec 15 17:26:39 2023 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 15 Dec 2023 17:26:39 +0100 (CET) Subject: [Daniel's week] December 15, 2023 Message-ID: <508n7sr1-66o6-3r76-2oss-q55182qr8212@unkk.fr> Hello friends. Another week ended. Just one more week left now before Christmas! ## Everything curl Back in 2015 when started writing the book Everything curl [1], I opted to use the service gitbook.com since it seemed like a low friction and convenient way to make a markdown book available online. I had already used it for my other book experiments so I knew how it worked. One part of that convenience was how they provided a link for users to download a PDF version. Handy. Several years into this journey, the good people at gitbook however for some reason decided to remove that feature and therefore there has been no PDF version of Everything curl for a while. Every once in a while users have asked for it. This week, I finally stopped delaying what had to be done and I wrote up a set of scripts to provide this service to users. Now, my scripts run daily and we can now provide not only a fresh PDF version [2] but also an ePUB one [3]. The PDF version at least looks pretty good! Including the 26 page (!) table of contents, the entire thing is over 500 pages long. I have not checked the ePUB version closer, so I hope someone will tell me if it needs polish. Glancing through the PDF version I could not help finding mistakes and details that were out of date and I have subsequently merged a whole series of updates and polish. I also started filing issues [4] about recent curl details and features that are not yet described in the book at all, just to make it visible and possibly lure others to help me out to write contents for this. ## FOSDEM I have a talk confirmed. I will talk about curl in the network devroom at FOSDEM 2024: "Broom not included: curling the modern way". There is no set time yet. My other two FOSDEM talk proposals are still unknowns and pending. I suppose they have not been handled yet, so neither denied nor confirmed. ## no patch We started out this week deliberating back and forth if we should do a patch release or not following the dot-zero release last week. We had a rather annoying regression in 8.5.0 which makes a specific test case permafail when you run the test suite as shipped in the release tarball because of a script that we managed to not include in the distribution. Eventually I decided not to do a patch release. Primarily because not that many people seem to actually have a problem with this test failure. We have not drowned in bug reports or people repeatedly shouting at as about it. Presumably because people find the information we provide or that not too many people actually are bothered about a single test failure. Maybe there aren't that many peeps out in the wild who run the curl tests? The other reason for not doing it would be from the other end: I rather avoid it if I can, since there is a lot of work to get it done. Documentation, lining up ducks in rows, doing a video etc. Skipping a release made this week more relaxed for me personally. Of course, I filled it up with curl work anyway. So instead of a patch release, we look forward to open the feature window tomorrow Saturday. ## code quality Following up pretty much what I wrote about in my weekly email last week [5], I wrote my blog post "Making it harder to do wrong" [6] elaborating on how we write C code and I got to show the graph with number of lines of code per cpy and per alloc. I have also now added that graph to the curl dashboard so that I can keep an eye on how this develops going forward. It is easy to work on cleanups as single-shots and then over time afterward forget about it and then slowly over time just relapse back to old non-optimal patterns. I hope my graphs can help me reduce that risk. ## business There seems to only be some minor formalities left now before I can start working on curl for XYZ, where I will maintain the port and also offer binary downloads going forward. The real name behind "XYZ" will be revealed to you all in due time, as I will for sure talk about this once it starts happening for real. Another development contract was delayed as the organization that requested a particular curl task/feature is now fund-raising to ideally soon be able to. I learned this week that a well-known large consumer electronics company experiences problems with curl in their product and we just need to get the support contract up and then I presumably will get my hands on crash reports from users around the world in order to help nailing down this. Together with two fellows in team curl, I am working on an application to ask a foundation for money for a multi-month project to enhance HTTP/3 and testing in curl. Ideally we can submit this next week. Fingers crossed. ## book I am frequently contacted by various companies and persons for all sorts of different book offers. Mostly I'm being asked if I want to write a book about some of the topics that I fiddle the most with. I really do not. I don't believe in writing books for profit. Way to much effort and too little return. I rather stick to writing books for free. This week, I was again contacted and I actually responded this time and there is now a communication going to see if there is something to work out and maybe, MAYBE, I can contribute to a book around HTTP without actually being the main author. I'm casually skeptical. ## Canada I have been invited to talk in Montreal, Canada, in May 2024. The company has accepted my compensation request so I am proceeding with further details now. It might mean that I will actually do this. If it ends up becoming reality, I will of course have to arrange more side meetings and activities in the area while there. I'll keep you updated in future emails but if you already now have ideas, let me know! ## h3 audit The curl HTTP/3 audit by Trail of Bits is ongoing. The majority of work is meant to be done this and next week, but then it might take a little longer until we have a report to make public. Can't wait to see what goodies they find! ## Coming up - Saturday: the curl feature window opens ## Links [1] = https://everything.curl.dev/ [2] = https://daniel.haxx.se/everything-curl/everything-curl.pdf [3] = https://daniel.haxx.se/everything-curl/everything-curl.epub [4] = https://github.com/bagder/everything-curl/issues [5] = https://lists.haxx.se/pipermail/daniel/2023-December/000044.html [6] = https://daniel.haxx.se/blog/2023/12/13/making-it-harder-to-do-wrong/ -- / daniel.haxx.se From daniel at haxx.se Fri Dec 22 17:50:24 2023 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 22 Dec 2023 17:50:24 +0100 (CET) Subject: [Daniel's week] December 22, 2023 Message-ID: Hello friends, I kept myself occupied another week. ## everything curl I must say that the new PDF version of Everything curl [3] that I fixed last week turned out to be a nice way for me to read through parts of the book again and when doing that I found lots of tiny mistakes and places that needed updates. Which subsequently made me merge two dozen commits or something in the beginning of the week. ## rtos The deal with a company doing a commercial RTOS has gone through. I'm still awaiting on some practical details to be arranged properly before my work can begin for real. I'll spill the beans properly once I do. Presumably in the first weeks of next year. "The deal" means that I will work on making curl run smoothly on their OS and provide binary packages for download on curl.se to users of that OS. ## printf In the libcurl code we use a lot of printf-style calls, and all of them use our internal printf implementation. I have preciously sped up a lot of functions by *avoiding* using printf and instead rather use other functions but this week I decided to take a closer look under this hood. Lots of libcurl code still uses and will remain using printf in various forms. The printf implementation is mostly code that originates from an implementation I and Bjorn Reese wrote before I started on curl. Old is not strong enough to describe it. Lots (most?) of the lines in that source code file were older than twenty years according to git blame. The internal implementation was originally written to make sure we can use snprintf() on all platforms, since once upon the time it was not universally available. It then became a way for us to make sure out printf uses work exactly the same everywhere. I also had the (bad) idea to add the printf functions to the public libcurl API so applications can use them. I consider it a bad idea partly because it means we are stuck having to support a full fledged printf even if we don't use all the features internally and removing some of them could certainly be beneficial for performance. Another reason it was a bad idea is that it is not transfer related and libcurl should not provide APIs for non-transfer activities. I started by writing a small application that uses a lot of snprintf() calls with many %s, %d, %c etc. Basically lots of the most commonly used %-specifiers with most common version (for libcurl code) of printf calls. I then measured how fast it ran when using current libcurl as well as how it compared to the glibc version of snprintf. It turned out that libcurl was mostly on part with glibc, speed-wise. I then switched to a debug-build version of libcurl and ran the same code again and used that as the base metric. That test code did 1.4 million printf calls at an average of 821 nanoseconds per snprintf (in a best of five runs). I tested various tweaks and polished away things I thought could have an impact, and I reran the speed test between every tweak. If the tweak seemed to have an impact, even if very small, I kept it and moved on to the next little thing. This way, over a few hours of poking and iterating over lots of smaller edits, I had squeezed the time down to 675 nanoseconds with no functional difference. Not too shabby! Quite happy with this, I added a few new test cases to the test suite and boom, now I realized that for a particular use case there was a rather ugly discrepancy between what the curl printf code did and how glibc (and probably POSIX) behaves. I pondered on ways to fix this problem that involved how to do when a %-qualifier is used but with no legal printf character following. Like %K or %r. It was one of those challenges that was hard to let go and it kept my brain spinning for a night and the morning after I knew what I had to do: I need to do a rather drastic rewrite of the code so that it would more clearly 1) parse the format string 2) generate a list of input arguments and their types 3) generate a list of output segments and their formatting options and 4) a function that combines and generates the output based on the previous steps. It sounds simple, but the existing code did not do the stages separated this distinctly which made it hard to fix that bug. Luckily we have a lot of printf test cases in the curl test suite and since curl uses printf a lot internally, I could basically hammer on the code, re-run the test suite, fix the problems and then try again. Over and over until all the test cases would report success. When all the test cases ran fine again, I held my breath and reran the performance test again. Would the refactor perhaps ruin the improvements I previously achieved? Nope. The new version clocked in at 650 nanoseconds and after some further polish I timed it at 619. I then spent some additional time at editing the code for style, renamed some functions and variables etc to make the result "nice code". If I may say so, the new version of the printf code is a much easier read. This is code that is not hard to understand. Of course I still fear that there is some tiny detail I got wrong and that we have missed to add a test case for, but the code [2] is merged now and no static code analyzer or fuzzer has yet reported any problem with it. Maybe, just maybe, the ducks were mostly in a row this time! ## h3 audit Trail of Bits have worked on this security audit of the HTTP/3 components in curl and on the Thursday we got an update and progress report from them. They have not found any alarming problems which certainly is good, but they did spot several areas with room for improvements. I will mention one of them below. The audit continues a little bit more and then they will work on a report that will be presented next year, and if they find any security problems those problems will of course have to be handled correctly and responsibly before any such details can go public. I will of course tell you all about these thins as soon as I can. ## fuzzing Trail of Bits pointed out that curl's fuzzing coverage on OSS-Fuzz shrunk dramatically A YEAR AGO and nobody has noticed during all this time and this is a real concern since who knows what possible flaws we have missed due to this. It turns out the coverage drop was because of a build flaw that made it run without TLS enabled. Once we fixed this problem, the coverage rate increased back up to similar levels as before [1] and luckily enough it seems it could not find any new problems even though it had not been doing its full job for an extended period of time. Needless to say, we are now pondering what we should do to avoid this happening again. What support oss-fuzz can help us to notice this or what kind of automation we need to implement ourselves. Phew, that was bad! ## keyboard Just yesterday I started using a new mechanical keyboard. I am not going to talk much about it just yet since I think it needs a week or three of intense use before I can tell my honest opinion of how it works and what I think about it. I will detail everything in a blog post later. ## Coming up - Christmas. I am going to be slower than normal. Just relax. ## Links [1] = https://introspector.oss-fuzz.com/project-profile?project=curl [2] = https://github.com/curl/curl/pull/12563 [3] = https://everything.curl.dev/ -- / daniel.haxx.se From daniel at haxx.se Fri Dec 29 18:40:23 2023 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 29 Dec 2023 18:40:23 +0100 (CET) Subject: [Daniel's week] December 29, 2023 Message-ID: <5p6178qo-p0p4-52r2-4365-o78r72139098@unkk.fr> Hello! The last weekly email for 2023. Things happened this week as well, but maybe a little less than usual. ## Christmas Christmas and the end of the year season is generally a time to slow down a little and reflect over the past year and of course I too have done that. I wrote my blog post on the curl commits of 2023 [1] a few days ago, which actually made me miss the new number-of-committers-in-a-single-year curl record that was broken today when commits from the 188th author of the year was merged into the source code repository. It pleases me a lot to see this huge interest in helping out and I hope that we can retain the attention and energy into the future. ## FOSDEM One of my three talk proposals for FOSDEM 2024 was denied: the HTTP/3 related one. The current state is that one is accepted (about curl in the network room [2] - but I'm only getting a twenty minutes slot so it'll be an interesting challenge. I think it might become a rather information packed session with me talking fast! :-) The third talk I proposed that is still neither accepted or rejected I submitted for the main track, which I probably makes it not too likely to get accepted. ## Everything curl I figured out how to enable the dark mode toggle on the book website [3] (see the little thing on the top right corner). I have continued to polish existing content, reordered some sections and I have added a few more pages and entire sections with more information this week. I did a huge overhaul and mostly banned the use of the word "will" in text as I rewrote over 1200 lines to use present tense everywhere instead of future tense. "curl makes this" instead of "curl will make this". We surpassed 108,000 words in the book. I also added more CI jobs and checks that verify the content and the correctness of the syntax, titles, quoting and more. ## Security We received a security vulnerability reported over hackerone [4] today that seems to be accurate. Currently I think it might land as a "severity low" issue. This is the first one since the 8.5.0 release on December 6. As usual, all details will be revealed in association with the pending next release (end of January). We (the curl project) have completed all the formalities we need to and we have been accepted as a CVE Numbering Authority (CNA). We are now just waiting for the announcement and for getting our authentication tokens. I expect us to be able to get our own CVE Ids starting with this coming release. ## Coming up - I hear there's a new year coming ## Links [1] = https://daniel.haxx.se/blog/2023/12/25/the-curl-activity-of-2023/ [2] = https://fosdem.org/2024/schedule/event/fosdem-2024-1909-broom-not-included-curling-the-modern-way/ [3] = https://everything.curl.dev/ [4] = https://hackerone.com/curl -- / daniel.haxx.se