daniel:// stenberg://

you still can't edit toots on this thing?! It's not even federated!

I stand by that the original take was bad. After updates it is now a better but the fearmongering (the logo, the phrasing, the name) I still object to. Even if the researcher might actually in the end have something real to report. I've been told he has.

curl 8.15.0 Welcome to another curl release. A shorter cycle this time so we did not have time to merge many changes: there is just one logged. See below. This is the 269th release featuring 269 command line options. ## Release presentation At 10:00 CEST (08:00 UTC) today the release presentation is live-streamed on twitch. ## Numbers the 269th release 1 change 42 days (total: 9,980) 233 bugfixes (total: 12,282) 334 commits (total: 35,572) 0 new public libcurl function (total: 96) 0 new curl_easy_setopt() option (total: 308) 0 new curl command line option (total: 269) 57 contributors, 29 new (total: 3,460) 37 authors, 16 new (total: 1,392) 0 security fix (total: 167) ## Change Removed support for Secure Transport and BearSSL. ## Bugfixes We manage to yet again land over 230 documented bugfixes (5.5 per day!). Read about them in the full changelog. A set of them are discussed in the release video.

My gut feeling says you need a new #curl release. So here is curl 8.15.0 just for you.

https://daniel.haxx.se/blog/2025/07/16/curl-8-15-0/

Death by a thousand slops I have previously blogged about the relatively new trend of AI slop in vulnerability reports submitted to curl and how it hurts and exhausts us. This trend does not seem to slow down. On the contrary, it seems that we have recently not only received more AI slop but also more _human slop_. The latter differs only in the way that we cannot immediately tell that an AI made it, even though we many times still suspect it. The net effect is the same. The general trend so far in 2025 has been _way more_ AI slop than ever before (about 20% of all submissions) as we have averaged in about two security report submissions per week. In early July, about 5% of the submissions in 2025 had turned out to be genuine vulnerabilities. The valid-rate has decreased _significantly_ compared to previous years. We have run the curl Bug Bounty since 2019 and I have previously considered it a success based on the amount of genuine and real security problems we have gotten reported and thus fixed through this program. 81 of them to be exact, with over 90,000 USD paid in awards. ## End of the road? While we are not going to do anything rushed or in panic immediately, there are reasons for us to consider changing the setup. Maybe we need to drop the monetary reward? I want us to use the rest of the year 2025 to evaluate and think. The curl bounty program continues to run and we deal with everything as before while we ponder about what we can and should do to improve the situation. For the sanity of the curl security team members. We need to reduce the amount of sand in the machine. We must do something to drastically reduce the temptation for users to submit low quality reports. Be it with AI or without AI. The curl security team consists of seven team members. I encourage the others to also chime in to back me up (so that we act right in each case). Every report thus engages 3-4 persons. Perhaps for 30 minutes, sometimes up to an hour or three. Each. I personally spend an insane amount of time on curl already, wasting three hours still leaves time for other things. My fellows however are not full time on curl. They might only have three hours per week for curl. Not to mention the _emotional toll_ it takes to deal with these mind-numbing stupidities. Times _eight_ the last week alone. ## Reputation doesn’t help On HackerOne the users get their _reputation_ lowered when we close reports as _not applicable_. That is only really a mild “threat” to experienced HackerOne participants. For new users on the platform that is mostly a pointless exercise as they can just create a new account next week. Banning those users is similarly a rather toothless threat. Besides, there seem to be so many so even if one goes away, there are a thousand more. ## HackerOne It is not super obvious to me exactly _how_ HackerOne should change to help us combat this. It is however clear that we need them to do something. Offer us more tools and knobs to tweak, to save us from drowning. If we are to keep the program with them. I have yet again reached out. We will just have to see where that takes us. ## Possible routes forward People mention charging a fee for the right to submit a security vulnerability (that could be paid back if a proper report). That would probably slow them down significantly sure, but it seems like a rather hostile way for an Open Source project that aims to be as open and available as possible. Not to mention that we don’t have any current infrastructure setup for this – and neither does HackerOne. And managing money is painful. Dropping the monetary reward part would make it much less interesting for _the general populace_ to do random AI queries in desperate attempts to report something that could generate income. It of course also removes the traction for some professional and highly skilled security researchers, but maybe that is a hit we can/must take? As a lot of these reporters seem to _genuinely_ think they help out, apparently blatantly tricked by the marketing of the AI hype-machines, it is not certain that removing the money from the table is going to completely stop the flood. We need to be prepared for that as well. Let’s burn that bridge if we get to it. ## The AI slop list If you are still innocently unaware of what AI slop means in the context of security reports, I have collected a list of a number of reports submitted to curl that help showcase. Here’s a snapshot of the list from today: 1. [Critical] Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet. #2199174 2. Buffer Overflow Vulnerability in WebSocket Handling #2298307 3. Exploitable Format String Vulnerability in curl_mfprintf Function #2819666 4. Buffer overflow in strcpy #2823554 5. Buffer Overflow Vulnerability in strcpy() Leading to Remote Code Execution #2871792 6. Buffer Overflow Risk in Curl_inet_ntop and inet_ntop4 #2887487 7. bypass of this Fixed #2437131 [ Inadequate Protocol Restriction Enforcement in curl ] #2905552 8. Hackers Attack Curl Vulnerability Accessing Sensitive Information #2912277 9. (“possible”) UAF #2981245 10. Path Traversal Vulnerability in curl via Unsanitized IPFS_PATH Environment Variable #3100073 11. Buffer Overflow in curl MQTT Test Server (tests/server/mqttd.c) via Malicious CONNECT Packet #3101127 12. Use of a Broken or Risky Cryptographic Algorithm (CWE-327) in libcurl #3116935 13. Double Free Vulnerability in `libcurl` Cookie Management (`cookie.c`) #3117697 14. HTTP/2 CONTINUATION Flood Vulnerability #3125820 15. HTTP/3 Stream Dependency Cycle Exploit #3125832 16. Memory Leak #3137657 17. Memory Leak in libcurl via Location Header Handling (CWE-770) #3158093 18. Stack-based Buffer Overflow in TELNET NEW_ENV Option Handling #3230082 19. HTTP Proxy Bypass via `CURLOPT_CUSTOMREQUEST` Verb Tunneling #3231321 20. Use-After-Free in OpenSSL Keylog Callback via SSL_get_ex_data() in libcurl #3242005 21. HTTP Request Smuggling Vulnerability Analysis – cURL Security Report #3249936

Death by a thousand slops

https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/

#curl #AI #bugbounty

Sponsor my laptop! I need to get myself a new laptop. My existing one is from 2017 and was already then not the most powerful one. It recently started to shut itself off when running on battery and during the two most recent curl up meetings it has proven itself to be rather sluggish and unable to save a live camera-recording while also streaming it, without stuttering or having other problems. A framework laptop I plan to get a new 13″ one from Framework, and a semi-beefy one from there runs at about 2,500 USD. I’m looking at roughly this configuration. ## The curl fund pays For the first time ever, the curl fund is going to help pay for this. The curl fund is all donations and sponsorships gathered. Money we only spend to improve curl and curl related activities. All my machines I have ever used to develop curl on up until now have been paid for by me personally. ## You can help! For this special occasion, we have created a small “crowd-source” like effort. You can help sponsor me this device and we have special little collectors pool for it here: https://opencollective.com/curl/contribute/laptop-90642 If we get more than 1,000 USD donated to this, I can upgrade my laptop config. More CPU, more memory, more storage perhaps. If this effort gets less than 1,000 donated, then I will stick to with the original “base” setup. For everyone who donate 200 USD (or more) I offer space on the laptop cover for the donor to decide exactly what I should put there (in terms of stickers etc). This program will run for a week as a start. ## A developer’s device I do my main curl development on a desktop PC in my home office. I use my laptop primarily when away, on travels and on vacations. I bring it to talks (10-15 a year) where I typically talk about curl or curl adjacent topics. I occasionally use it to live-stream with, like from our annual curl up meetings. I have decided to go with Framework because I like their concept and I hear good things about them. I run Linux. I prefer Debian. That is what I intend to use on this one as well. ## The fund We have a few regular gracious sponsors of the curl project that donates money to us on a regular basis. Their money is what pays for this if nobody else wants to participate.

Sponsor my laptop!

https://daniel.haxx.se/blog/2025/07/12/sponsor-my-laptop/

For #curl of course. What else would I ever do?

yeah, my fault. Wasn't paying attention...

Curl Fights a Flood of AI-Generated Bug Reports From HackerOne Curl maintainer Daniel Stenberg is combating a flood of "AI slop" by requiring contributors to disclose AI use and meticulously verify findings.

Curl maintainer @daniel.haxx.se is combating a flood of "AI slop" by requiring contributors to disclose AI use and meticulously verify findings.

Maybe this hints I should do more proper posts here...

Sketch notes showing various open source maintainership terms and a quote to 'have fun'

Next up at #JoyOfCoding 2025 was @daniel.haxx.se to talk about curl and accidental world domination 😅

A flow chart for how curl connects to which host when doing HTTP

How does #curl connect to which host when doing HTTP? First draft.

curl 8.14.0 Welcome to another curl release. ## Release presentation At 8:00 UTC (10:00 CEST), I do a live-streamed release presentation over at Twitch where I talk about all that is new in this release. ## Numbers the 267th release 6 changes 56 days (total: 9,931) 229 bugfixes (total: 12,015) 406 commits (total: 35,190) 0 new public libcurl function (total: 96) 1 new curl_easy_setopt() option (total: 308) 1 new curl command line option (total: 269) 89 contributors, 47 new (total: 3,426) 36 authors, 17 new (total: 1,375) 2 security fixes (total: 166) ## Security * CVE-2025-4947: QUIC certificate check skip with wolfSSL * CVE-2025-5025: No QUIC certificate pinning with wolfSSL ## Changes * When doing MQTT, curl now sends pings * The Schannel backend now supports pkcs12 client certificates containing CA certificates * Added `CURLOPT_SSL_SIGNATURE_ALGORITHMS` and `--sigalgs` for the OpenSSL backend * ngtcp2 + OpenSSL’s new QUIC API is now supported. Requires OpenSSL 3.5 or later. * wcurl comes bundled in the curl tarball * websocket can now disable auto-pong ## Bugfixes See the changelog on the curl site for the full set, or watch the release presentation for a “best of” collection.

#curl 8.14.0 is here with new stuff, bugfixes and two security advisories.

Live-streamed presentation at 08:00 UTC today.

https://daniel.haxx.se/blog/2025/05/28/curl-8-14-0/

Curl vs AI with Daniel Stenberg Daniel Stenberg, the maintainer of Curl, discusses the increase in AI security reports that are wasting the time of maintainers. We discuss Curl’s new policy of banning the bad actors while establishi...

I chatted with @daniel.haxx.se about #Curl and the recent #AI happenings

It's always fun talking to Daniel, and I think there's a lot of good ideas in this one, especially on how to approach AI fueled contributions that aren't slop. And even suggestions on how to deal with slop contributions :)

I've heard him go on like that on @twit.tv a few times, and I get the impression the other guests in those episodes have not been developers enough to question the madness.

He lives and operates on a different planet than mine, for sure.

The curl user survey 2025 is up Yes! curl user survey 2025 The time has come for you to once again do your curl community duty. Run over and fill in the curl user survey and tell us about how you use curl etc. This is the only proper way we get user feedback on a wide scale so please use this opportunity to tell us what you really think. This is the 12th time the survey runs. It is generally similar to last year’s but with some details updated and refreshed. The survey stays up for fourteen days. Tell your friends. curl user survey 2025

The #curl user survey 2025 is up. Please donate a few minutes of your time and tell us about your view and use of curl.

https://daniel.haxx.se/blog/2025/05/19/the-curl-user-survey-2025-is-up/

0 days since the latest slop

0 days since the latest slop

On that note, huge thanks to @daniel.haxx.se for allowing me to copy & extend curl's recent AI guidelines for my projects. I've just added a corresponding section to OctoPrint's Contribution Guidelines and Security Policy:

github.com/OctoPrint/Oc...

octoprint.org/security/

If you can donate a few minutes of your time, I and the team will appreciate it greatly. Thanks!

If you can donate a few minutes of your time, I and the team will appreciate it greatly. Thanks!

Woo, thanks @daniel.haxx.se for the mention in your recent post <3

Detecting malicious Unicode In a recent educational trick, curl contributor James Fuller submitted a pull-request to the project in which he suggested a larger cleanup of a set of scripts. In a later presentation, he could show us how not a single human reviewer in the team nor any CI job had spotted or remarked on one of the changes he included: he replaced an ASCII letter with a Unicode alternative in a URL. This was an eye-opener to several of us and we decided we needed to up our game. We are the curl project. We can do better. ## GitHub The replacement symbol looked identical to the ASCII version so it was not possible to visually spot this, but the diff viewer knows there is a difference. In this GitHub website screenshot below I reproduced a similar case. The right-side version has the Latin letter ‘g’ replaced with the Armenian letter co. They appear to be the same. GitHub shows a diff. But what is actually the difference? The diff viewer says there is a difference but as a human it isn’t possible to detect what it is. Is it a flaw? Does it matter? If done “correctly”, it would be done together with a _real_ and expected fix. The impact of changing one or more letters in a URL can of course be devastating depending on conditions. When I flagged about this rather big omission to GitHub people, I got barely no responses at all and I get the feeling the impact of this flaw is not understood and acknowledged. Or perhaps they are all just too busy implementing the next AI feature we don’t want. ## Warnings When we discussed this problem on Mastodon earlier this week, Viktor Szakats provided me with an example screenshot of doing a similar stunt with Gitea which quite helpfully highlights that there is something special about the replacement: Gitea warns that the replacement is using “ambiguous Unicode characters” I have been told that some of the other source code hosting services also show similar warnings. As a user, I would actually like to know even more than this, but at least this warns about the proposed change clearly enough so that if this happens I would get the code manually and investigate before accepting such a change. ## Detect While we wait for GitHub to wake up and react (which I have no expectation will actually happen anytime soon), we have implemented checks to help us poor humans spot things like this. _To detect malicious Unicode._ We have added a CI job that scans all files and validates every UTF-8 sequence in the git repository. In the curl git repository most files and most content are plain old ASCII so we can “easily” whitelist a small set of UTF-8 sequences and some specific files, the rest of the files are simply not allowed to use UTF-8 at all as they will then fail the CI job and turn up red. In order to drive this change home, we went through all the test files in the curl repository and made sure that all the UTF-8 occurrences were instead replaced by other kind of escape sequences and similar. Some of them were also used more or less by mistake and could easily be replaced by their ASCII counterparts. The next time someone tries this stunt on us it could be someone with less good intentions, but now ideally our CI will tell us. ## Confusables There are plenty of tools to find similar-looking characters in different Unicode sets. One of them is provided by the Unicode consortium themselves: https://util.unicode.org/UnicodeJsps/confusables.jsp ## Reactive This was yet another security-related fix _reacting_ on a demonstrated problem. I am sure there are plenty more problems which we have not yet thought about nor been shown and therefore we do not have adequate means to detect and act on automatically. We want and strive to be proactive and tighten everything _before_ malicious people exploit some weakness somewhere but security remains this never-ending race where we can only do the best we can and while _the other side_ is working in silence and might at some future point attack us in new creative ways we had not anticipated. That future unknown attack is a tricky thing.

Detecting malicious Unicode in #curl

https://daniel.haxx.se/blog/2025/05/16/detecting-malicious-unicode/

I'm still waiting for an AI to actually find a real problem one day. People keep saying they can do that.

Hello

Joint Letter on Swedish Data Storage and Access to Electronic Information Legislation To sign this open letter, please do so here: https://app.smartsheet.com/b/form/e3cf0c35c3a84837b0accdf21966a554 —-- The undersigned civil society organizations, companies, and cybersecurity experts, including members of the Global Encryption Coalition, urgently call for the Swedish Riksdag to...

Joint Letter on Swedish Data Storage and Access to Electronic Information Legislation

Accepting signatures of the letter until 13.00 UTC on Monday, 7 April 2025

https://docs.google.com/document/d/1eA7kCixXTIWimLIiUBBqAcAcvo6me4ywtNPyzGbwn6E/edit?tab=t.0

I signed

Jag hör att alla kids har keps på sig bakåfram, kör på det! 😁

Tell me which primary challenges you see!

for sure; we keep developing curl at a fairly high pace so there is no doubt in my mind that we do occasional slip-ups that keen eyes will find down the line!

Not so subtle attempts

That's so yesterday

curl up logo

Did you know that YOU can sponsor this year's #curl up? curl up is the annual curl developers meetup, this year taking place in May in Prague.

You can have your company name associated with the event while at the same time funding critical Internet […]

[Original post on mastodon.social]