I’m happy to announce that we yet again completed a full eight week release cycle and as customary, we end it with a fresh release. Enjoy!
Starting 8:00 UTC on March 31, 2021 there will be a live-streamed release presentation done over twitch. The live-stream will start a bit earlier if anyone has questions or just want to casually hang out a bit first.
the 198th release
6 changes
56 days (total: 8,412)
130 bug fixes (total: 6,812)
226 commits (total: 26,978)
0 new public libcurl function (total: 85)
3 new curl_easy_setopt() option (total: 288)
3 new curl command line option (total: 240)
58 contributors, 34 new (total: 2,356)
24 authors, 11 new (total: 871)
2 security fixes (total: 100)
800 USD paid in Bug Bounties (total: 5,200 USD)
CVE-2021-22876 is the first curl CVE of 2021.
libcurl did not strip off user credentials from the URL when automatically populating the Referer:
HTTP request header field in outgoing HTTP requests, and therefore risks leaking sensitive data to the server that is the target of the second HTTP request.
libcurl automatically sets the Referer:
HTTP request header field in outgoing HTTP requests if the CURLOPT_AUTOREFERER
option is set. With the curl tool, it is enabled with --referer ";auto"
.
Rewarded with 800 USD
CVE-2021-22890 is a flaw in curl’s OpenSSL backend that allows a malicious HTTPS proxy to trick curl with session tickets and subsequently allow the proxy to MITM the remote server. The problem only exists with OpenSSL and it needs to speak TLS 1.3 with the HTTPS proxy – and the client must accept the proxy’s certificate, which has to be especially crafted for the purpose.
Note that an HTTPS proxy is different than the mode comon HTTP proxy.
The reporter declined offered reward money.
We list 6 “changes” this time around. They are…
The command line option for setting cookies can now be used multiple times on the command line to specify multiple cookies. Either by setting cookies by name or by providing a name to a file to read cookie data from.
The command line tool has had the --fail
option for a very long time. This new option is very similar, but with a significant difference: this new option saves the response body first even if it returns an error due to HTTP response code that is 400 or larger.
When telling curl to use DoH to resolve host names, you can now specify that curl should ignore the TLS certificate verification for the DoH server only. Independently of how it treats other TLS servers that might be involved in the transfer.
This is done with the new CURLINFO_REFERER
libcurl option and with the command line tool, --write-out '%{referer}
‘.
For SASL authentication done with mail-using protocols such as IMAP and SMTP.
A new optional TLS backend. This is provided via crustls, a C API for the rustls TLS library.
Again we’ve logged over a hundred fixes in a release, so here goes some of my favorite corrections we did this time:
CURLOPT_NEW_FILE_PERMS
if requestedDue to a silly mistake in the previous release, the new --create-file-mode
didn’t actually work because it didn’t set the permissions with libcurl properly – but now it does.
When resolving host names with DoH, the transfers done for that purpose now “inherit” the same --resolve
info as used for the normal transfer, which I guess most users already just presumed it did…
Virtually all internal buffers have length restrictions for security and the maximum size we allowed for a single HTTP request was previously 128 KB. A user with a use-case sending a single 300 KB header turned up and now we allow HTTP requests to be up to 1 MB! I can’t recommend doing it, but now at least curl supports it.
In a recent change I made SIZE failures get treated as “file not found” error, but it introduced this regression for resumed uploads because when resuming a file upload and there’s nothing uploaded previously, SIZE is then expected to fail and it is fine.
The torture tests scored another victory when it proved that when the connection failed at just the correct moment after an FTP transfer is complete, curl could skip a free() and leak memory.
When a HTTP/2 connection is (prematurely) terminated, streams over that connection could return “closed” internally without noticing the premature part. As there was no previous END_STREAM message received for the stream(s), curl should consider that an error and now it does.
A rare race condition in the HTTP/2 code could make libcurl remain expecting to send data when in reality it had already delivered the last chunk.
Another cleanup in the code that had the potential to get wrong in the future and mostly worked right now due to lucky circumstances. In HTTP each request done can use its own set of credentials, so it is vital to not use “connection bound” credentials but rather the “transfer oriented” set. That way streams and requests using different credentials will work fine over a single connection even when future changes alter code paths.
A rather large internal refactor that shouldn’t be visible on the outside to anyone: transfer objects now link to the corresponding connection object like before, but now connection objects do not link to any transfer object. Many transfers can share the same connection.
The seemingly never-ending work to make a version 3 of OpenSSL keeps changing the API and curl is adapting accordingly so that we are prepared and well functioning with this version once it ships “for real” in the future.
Otherwise libcurl is likely to reuse the same (wrong) connection again in the next transfer attempt since the connection reuse logic doesn’t take downgrades into account!
The rate limiting logic was previously not correctly applied on the initial body chunk that libcurl sends. Like if you’d tell libcurl to send 50K data with CURLOPT_POSTFIELDS and limit the sending rate to 5K/second.
I’ll go for an extra fine cup of coffee today after I posted this. I think I’m worth it. I bet you are too. Go ahead and join me: Hooray for another release!