Tag Archives: release

Why no curl 8

no 8In this little piece I'll explain why there won't be any version 8 of curl and libcurl in a long time. I won't rule out that it might happen at some point in the future. Just that it won't happen anytime soon and explain the reasons why.

Seven point twenty nine, really?

We've done 29 minor releases and many more patch releases since version seven was born, on August 7 2000. We did in fact bump the ABI number a couple of times so we had the chance of bumping the version number as well, but we didn't take the chance back then and these days we have a much harder commitment and determinism to not break the ABI.

There's really no particular downside with having a minor version 29. Given our current speed and minor versioning rules, we'll bump it 4-6 times/year and we won't have any practical problems until we reach 256. (This particular detail is because we provide the version number info with the API using 8 bits per major, minor and patch field and 8 bits can as you know only hold values up to 255.) Assuming we bump minor number 6 times per year, we'll reach the problematic limit in about 37 years in the fine year 2050. Possibly we'll find a reason to bump to version 8 before that.

Prepare yourself for seven point an-increasingly-higher-number for a number of years coming up!

Is bumping the ABI number that bad?

Yes!

We have a compatibility within the ABI number so that a later version always work with a program built to use the older version. We have several hundred million users. That means an awful lot of programs are built to use this particular ABI number. Changing the number has a ripple effect so that at some point in time a new version has to replace all the old ones and applications need to be rebuilt - and at worst also possibly have to be rewritten in parts to handle the ABI/API changes. The amount of work done "out there" on hundreds or thousands of applications for a single little libcurl tweak can be enormous. The last time we bumped the ABI, we got a serious amount of harsh words and critical feedback and since then we've gotten many more users!

Don't sensible systems handle multiple library versions?

Yes in theory they do, but in practice they don't.

If you build applications they have the ABI number stored for which lib to use, so if you just keep the different versions of the libraries installed in the file system you'll be fine. Then the older applications will keep using the old version and the ones you rebuild will be made to use the new version. Everything is fine and dandy and over time all rebuilt applications will use the latest ABI and you can delete the older version from the system.

In reality, libraries are provided by distributions or OS vendors and they ship applications that link to a specific version of the underlying libraries. These distributions only want one version of the lib, so when an ABI bump is made all the applications that use the lib will be rebuilt and have to be updated.

Most importantly, there's no pressing need!

If we would find ourselves cornered without ability to continue development without a bump then of course we would take the pain it involves. But as things are right now, we have a few things we don't really like with the current API and ABI but in general it works fine and there's no major downsides or great pains involved. We simply do not have any particularly good reason to bump version number or ABI version. Things work pretty good with the current way.

The future is of course unknown and at some point we'll face a true limitation in the API that we need to bridge over with a bump, but it can also take a long while until we hit that snag.

Update April 6th: this article has been read by many and I've read a lot of comments and some misunderstandings about it. Here's some additional clarifications:

  1. this isn't stuff we've suddenly realized now. This is truths and facts we've learned over a long time and this post just makes it more widely available and easier to find. We already worked with this knowledge. I decided to blog about it since it struck me we didn't have it documented anywhere.
  2. not doing version 8 (in a long time) does not mean we're done or that the pace of development slows down. We keep doing releases bimonthly and we keep doing an average of 30 something bugfixes in each release.

curl and libcurl 7.29.0

As a representative for the team behind curl and libcurl, we're of course proud to yet again having shipped a release to the public today. Over 240 commits, with in total almost 10000 lines added and 6000 removed since the previous release in November 2012. We're only a month away until the curl project turns 15 years old.

Some highlights this time include:

  • We fixed a nasty overflow vulnerability we have been shipping in a few previous releases. The flaw existed in code used by IMAP, POP3 and SMTP.
  • We introduced a new test suite output mode that is "automake compliant". This can help linux distros and others who want to run many test suites and have a unified way of parsing the results and outcome. It follows the spirit of ptest and I believe it will be used in the future.
  • The IMAP support got a lot of improvements and lots of login and authentication fixes were brought in. Now libcurl supports the sasl methods digest-md5, cram-md5, ntlm and login., and it also recognizes the login disabled server capability.
  • Architecture wise, we remodeled the internals quite a lot and made it "always-multi". This improves readability and internal complexity and is all just goodness. The short-term downside is possibly the risk for a temporary increase in bug reports due to this...
  • 35 specified bug fixes were crammed in as well, and there are a bunch more we haven't mentioned that just "silently" improved the multi interface functionality.

News in curl 7.24.0

We continue doing curl releases roughly bi-monthly. This time we strike back with a release holding a few interesting new things that I thought are worth highlighting a little extra!

The most important and most depressing news about this release is the two security problems that were fixed. Never before have we released two security advisories for the same release.

Security fixes

The "curl URL sanitization vulnerability" is about how curl trusts user provided URL strings a little too much. Providing sneakily crafted URLs with embeded url-encoded carriage returns and line feeds users could trick curl to do un-intended actions when POP3, SMTP or IMAP protocols were used.

The "curl SSL CBC IV vulnerability" is about how curl inadvertently disables a security measurement in OpenSSL and thus weakens the security for some aspects of SSL 3.0 and TLS 1.0 connections.

Changes

We have a bunch of new changes added to curl and libcurl that some users might like:

  • curl has this ability to run a set of "extra commands" for a couple of protocols when doing a transfer - we call them "quote" operations. A while ago we introduced a way to mark commands within a series of quote commands as not being important if they fail and that the rest of the commands should be sent anyway. We mark such commands with a '*'-prefix. Starting now, we support that '*'-prefix for SFTP operations as well!
  • CURLOPT_DNS_SERVERS is a brand new option that allows programs to set which DNS server(s) libcurl should use to resolve host names. This function only works if libcurl was built to use a resolver backend that allows it to change DNS servers. That currently means nothing else but c-ares.
  • Now supports nettle for crypto functions. libcurl has long been supporting both OpenSSL and gcrypt backends for some of the crypto functions libcurl supports. The gcrypt made perfect sense when libcurl was built to use GnuTLS built to use gcrypt, but since GnuTLS recently has changed to using nettle by default the newly added support to use nettle with remove the need for an extra crypto link being linked for some users.
  • CURLOPT_INTERFACE was modified to allow "magic prefixes" for the application to tell that it uses an interface and not a host name and vice versa. The previous way would always test for both, which could lead to accidental (and slow) name resolves when the interface name isn't currently present etc.
  • Active FTP sessions with the multi interface are now done much more non-blocking than before. Previously the multi interface would block while waiting for the server to connect back but it no longer does. A new option called CURLOPT_ACCEPTTIMEOUT_MS was added to allow programs to set how long libcurl should wait for accepting the server getting back.
  • Coming in from the Debian packaging guys, the configure script how features a new option called --enable-versioned-symbols that does exactly what it is called: it enables versioned symbols in the output libcurl.

curl 7.22.0

Another release of curl and libcurl just happened. 7.22.0 is released.

Apart from the 28 something documented bug fixes, we introduce a range of changes that could be noteworthy:

  • Added CURLOPT_GSSAPI_DELEGATION - remember that we explicitly disabled GSSAPI delegation in our previous release due to a security problem. Now we introduce an option for the application to control exactly how to behave.
  • Added support for NTLM delegation to Samba's winbind daemon helper ntlm_auth. This lets libcurl use the external helper program to do things like NTLM single-sign on.
  • Display notes from setup file in testcurl.pl - provides a way for test clients to provide more information back to the centralized test summary on the primary server.
  • BSD-style lwIP TCP/IP stack experimental support on Windows - there are still flaws in lwIP on windows that prevents it from working properly
  • OpenSSL: Use SSL_MODE_RELEASE_BUFFERS if available - this is basically a way to ask OpenSSL to use less memory
  • --delegation was added to set CURLOPT_GSSAPI_DELEGATION - simply the new option exported to the command line tool
  • nss: start with no database if the selected database is broken - a slightly modified behavior
  • telnet: allow programatic use on Windows - basically making the windows implementation in sync with how the non-windows version already has worked for quite some time

This release is this great thanks to 25 friendly contributors.

cURL

Shipping curl 7.21.5

I don't usually post anything here when we do curl releases, pretty much because we do them bimonthly on a fairly steady schedule so there should be little surprise to anyone interested by the time they get public.

But hey, this is hard work and just to remind you all what's going on I thought I'd throw in a mention of what we've spent the last two months doing. curl and libcurl 7.21.5 is released today.

The five notable changes introduced this time include:

The CURLOPT_SOCKOPTFUNCTION callback can now return information back to libcurl that the socket libcurl operates on is already connected. This is useful for applications that do a lot of fiddling on their own and possibly provide its own socket to start with using the CURLOPT_OPENSOCKETFUNCTION.

curl the tool got support for the --netrc-file option, that allows a user to point out a specific .netrc file instead of always forcing the user to use the fixed $HOME/.netrc one.

Brand new support for building libcurl with the cyassl library for SSL/TLS support. Previously curl only had support for the older OpenSSL emulation API that cyassl used to provide, but starting now we're using cyassl directly and it is now a proper SSL citizen among the seven SSL libraries curl supports.

Since the previous release when we shipped the first support for TLS-SRP that required GnuTLS, the OpenSSL project accepted patches that introduced TLS-SRP into their official version as well and accordingly we have received patches that now allow users to use TLS-SRP with libcurl built against (a new enough) OpenSSL as well.

We have started to re-use two error codes a bit differently within libcurl, so that it now can return: CURLE_NOT_BUILT_IN (4) when an application tries to use a feature that was missing or was explicitly disabled at build-time and CURLE_UNKNOWN_OPTION (48) when the application has passed in an option that isn't known or recognized.

And we're counting more than 40 bugfixes worth mentioning. The most important ones are possibly:

If using the multi interface doing RTSP, libcurl could crash when trying to re-use a previous connection.

POP3 didn't do TLS properly, it issued the wrong command to start TLS and it didn't send the password correctly once it did switch to TLS!

When using the multi interface, there could be times when the timeout didn't trigger so it wouldn't close lingering connections even when asked to do so.

SFTP and SFP with the multi_socket interface were not working correctly and would very easily end up with stalled transfers due to the application being told to wait for the wrong action (or none at all).

If told to use the CCC command (which is used with FTP-SSL when the client asks the server to switch off from an SSL connection back to plain TCP again), curl would disable SSL on the connection but then use the wrong socket reader function and crash.

... but of course, if you've suffered from a particular bug in a previous release I'm sure you'll consider the exact bug fix that corrects your problem to be the most important one!

Not to forget, the great people apart from yours truly that have contributed with code and insights since the previous release. Without them, the above list of changes and bugfixes just wouldn't exist. The friends we have to thank are (in no particular order):

Mike Crowe, Kamil Dudka, Julien Chaffraix, Hoi-Ho Chan, Ben Noordhuis, Dan Fandrich, Henry Ludemann, Karl M, Manuel Massing, Marcus Sundberg, Stefan Krause, Todd A Ouska, Saqib Ali, Andre Guibert de Bruet, Tor Arntsen, Vincent Torri, Dave Reisner, Chris Smowton, Tinus van den Berg, Hongli Lai, Gisle Vanem, Andrei Benea, Mehmet Bozkurt

... and now back to working towards the next release. To be expected in roughly two months. Repeat.

libssh2 release again

libssh2We've mostly been fixing bugs and making things internally look better in the libssh2 source code during the recent months so the new release I just uploaded, called version 1.2.7, isn't really exciting to any particular level for outsiders. Existing users should however be fairly happy as we've addressed a fair bunch of bugs and some of them have been annoying us in the project for a long time.

I'm convinced this is the best libssh2 release we've ever made.

The list of bug-fixes include these:

  • Better handling of invalid key files
  • inputchecks: make lots of API functions check for NULL pointers
  • libssh2_session_callback_set: extended the man page
  • SFTP: limit write() to not produce overly large packets
  • agent: make libssh2_agent_userauth() work blocking properly
  • _libssh2_userauth_publickey: reject method names longer than the data
  • channel_free: ignore problems with channel_close()
  • typedef: make ssize_t get typedef without LIBSSH2_WIN32
  • _libssh2_wait_socket: poll needs milliseconds
  • libssh2_wait_socket: reset error code to "leak" EAGAIN less
  • Added include for sys/select.h to get fd.set on some platforms
  • session_free: free more data to avoid memory leaks
  • openssl: make use of the EVP interface
  • Fix underscore typo for 64-bit printf format specifiers on Windows
  • Make libssh2_debug() create a correctly terminated string
  • userauth_hostbased_fromfile: packet length too short
  • handshake: Compression enabled at the wrong time
  • Don't overflow MD5 server hostkey

If you find other bugs or have patches, just bring them all to us!

a big curl forward

We're proudly presenting a major new release of curl and libcurl and we call it 7.20.0.

The primary reason we decided to bump the minor number this time was that we introduce a range of new protocols, but we also did some other rather big works. This is the biggest update to curl and libcurl that have been made in recent years. Let me mention some of the other noteworthy changes and bugfixes:

We fixed a potential security issue, that would occur if an application requested to download compressed HTTP content and told libcurl to automatically uncompress it (CURLOPT_ENCODING) as then libcurl could wrongly call the write callback (CURLOPT_WRITEFUNCTION) with a larger buffer than what is documented to be the maximum size.

TFTP was finally converted to a "proper" protocol internally. By that I mean that it can now be used with the multi interface in an asynchronous way and it has far less special treatments. It is now "just another protocol" basically and that is a good thing. Also, the BLKSIZE problem with TFTP that has haunted us for a while was fixed so I really think this is the best version ever for TFTP in libcurl.

In several different places in the code older versions of libcurl didn't properly call the progress callback while waiting for some special event to happen. This made the curl tool's progress meter less responding but perhaps more importantly it prevented apps that use libcurl to abort the transfer during those phases. The affected periods included the ftp connection phase (including the initial FTP commands and responses), waiting for the TCP connect to complete and resolving host names using c-ares.

The DNS cache was found to have at least two bugs that could make entries linger in the database eternally and in another case too long. For apps that use a lot of connections to a lot of hosts, these problems could result in some serious performance punishments when the DNS cache lookups got slower and slower over time.

Users of the funny ftp server drftpd will appreciate that (lib)curl now support the PRET command, which is needed when getting data off such servers in passive mode. It's a bit of a hack, but what can we do? We didn't invent it nor can we help that it's a popular thing to use! 😉

cURL

c-ares 1.7.0

The first c-ares release so far in 2009 took place today when we shipped c-ares 1.7.0 and uploaded it to the web site.

News this time include:

  • Added ares_library_init() and ares_library_cleanup()
  • Added ares_parse_srv_reply(), ares_parse_txt_reply() and ares_free_data()
  • in6_addr is not used in ares.h anymore, but a private ares_in6_addr is
    instead declared and used
  • ares_gethostbyname() now supports 'AF_UNSPEC' as a family for resolving
    either AF_INET6 or AF_INET
  • a build-time configured ares_socklen_t is now used instead of socklen_t
  • new --enable-curldebug configure option
  • ARES_ECANCELLED is now sent as reason for ares_cancel()
  • new --enable-symbol-hiding configure option
  • new Makefile.msvc for any MSVC compiler or MS Visual Studio version
  • addrttl and addr6ttl structs renamed to ares_addrttl and ares_addr6ttl
  • naming convention for libraries built with MSVC, see README.msvc

The set of bugfixes done include these:

  • ares_parse_*_reply() functions now return ARES_EBADRESP instead of
    ARES_EBADNAME if the name in the response failed to decode
  • only expose/export symbols starting with 'ares_'
  • fix \Device\TCP handle leaks triggered by buggy iphlpapi.dll
  • init without internet gone no longer fails
  • out of bounds memory overwrite triggered with malformed /etc/hosts file
  • function prototypes in man pages out of sync with ares.h

As usual, c-ares would be nothing without the fierce and skillful help provided by a team of volunteer hackers. We always need more help and assitance, join the c-ares mailing list and join in the fun!

c-ares

curl and libcurl 7.19.7

Time again for a happy release event. Can you believe  this is in fact the 113th release?cURL

Run over to the curl download page to get it!

This time, we bring happiness with the best curl and libcurl release ever and it features four changes and a range of bug fixes. The changes to note this time include:

And a collection of bugs fixed since the previous release involves these issues:

  • The windows makefiles work again
  • libcurl-NSS acknowledges verifyhost
  • SIGSEGV when pipelined pipe unexpectedly breaks
  • data corruption issue with re-connected transfers
  • use after free if we're completed but easy_conn not NULL (pipelined)
  • missing strdup() return code check
  • CURLOPT_PROXY_TRANSFER_MODE could pass along wrong syntax
  • configure --with-gnutls=PATH fixed
  • ftp response reader bug on failed control connections
  • improved NSS error message on failed host name verifications
  • ftp NOBODY on re-used connection hang
  • configure uses pkg-config for cross-compiles as well
  • improved NSS detection in configure
  • cookie expiry date at 1970-jan-1 00:00:00
  • libcurl-OpenSSL failed to verify some certs with Subject Alternative Name
  • libcurl-OpenSSL can load CRL files with more than one certificate inside
  • received cookies without explicit path got saved wrong if the URL had a query part
  • don't shrink SO_SNDBUF on windows for those who have it set large already
  • connect next bug
  • invalid file name characters handling on Windows
  • double close() on the primary socket with libcurl-NSS
  • GSS negotiate infinite loop on bad credentials
  • memory leak in SCP/SFTP connections
  • use pkg-config to find out libssh2 installation details in configure
  • unparsable cookie expire dates make cookies get treated as session coookies
  • POST with Digest authentication and "Transfer-Encoding: chunked"
  • SCP connection re-use with wrong auth
  • CURLINFO_CONTENT_LENGTH_DOWNLOAD for 0 bytes transfers
  • CURLINFO_SIZE_DOWNLOAD for ldap transfers (-w size_download)