Fixing a 20+ year old bug in Debian curl | Yet Another Me

18 May 2026

Tags:<br>debian,<br>debug,<br>curl,<br>english,<br>free-software

Fixing a 20+ year old bug in Debian curl

Table of Contents

I have been helping co-maintain the Debian curl package for a few<br>years now, and even though Samuel and Charles do most of the work, I&rsquo;m<br>happy to jump in and help when needed. This is one of those cases.

Nowadays the package is maintained by 3 people (with help from others<br>occasionally), but it hasn&rsquo;t always been like this. Samuel adopted<br>the package back in 2021, and since then it has received a lot of love<br>and care to make sure it lives up to Debian&rsquo;s standards. Again, kudos<br>to both him and Charles who have been doing great work on this front.<br>But a little more than 20 years ago, the situation in Debian (and<br>curl!) was &ldquo;a bit&rdquo; different.

Once upon a time…

According to d/changelog, the Debian curl maintainer in 2005<br>introduced changes to the packaging that allowed it to generate a<br>version of libcurl for each TLS backend available: OpenSSL and<br>GnuTLS. This meant that curl would have two binary library packages:

libcurl3-openssl and its respective -dev variant, for libcurl<br>linked against OpenSSL; and

libcurl3-gnutls and its respective -dev variant, for libcurl<br>linked against GnuTLS.

But then, around 2006/2007 or so, upstream curl decided to bump the<br>SONAME version of libcurl from 3 to 4. At the time, they apparently<br>did not version their library symbols like they do now, which<br>was… less than ideal. I don&rsquo;t judge them: curl and a lot of other<br>important projects have come a long way when we consider best<br>practices to write shared libraries.

Meanwhile, on Debian land, the release team was having trouble with<br>other transitions going on at the time. For those who are not versed<br>in Debian&rsquo;s vocabulary, a transition happens when a shared library<br>gets its SONAME version bumped: when this happens, we have to make<br>sure that all reverse dependencies of that library still build with<br>the new version, and fix things that fail. The more reverse<br>dependencies the library has, the harder this work gets.

When upstream curl bumping the SONAME version of libcurl, the Debian<br>curl maintainer at the time correctly renamed the binary packages from<br>libcurl3-{openssl,gnutls} (and their -dev variants) to<br>libcurl4-{openssl,gnutls} (and their -dev variants), which<br>obviously triggered a transition. And a big one, because libcurl is<br>used by several projects.

Long story short, the Debian release team found themselves between a<br>rock and a hard place. According to the late Steve Langasek at the<br>time:

We talked a while back about the curl transition, and about how upstream&rsquo;s<br>change from libcurl.so.3 to libcurl.so.4 is gratuitously painful for us in<br>light of the large number of reverse dependencies.

The libcurl transition has at this point gotten tangled with soname<br>transitions in jasper, exiv2, kexiv2, and God only knows what else. So I&rsquo;d<br>like to revisit this question, because tracking this transition is costing<br>the release team a lot of time that would be better spent elsewhere, and<br>removing the need for a libcurl transition promises to reduce the complexity<br>of the other components by an order of magnitude.

On looking at the curl package, I&rsquo;ve come to understand that the<br>symbol versioning in place in this library is the result of a<br>Debian-local patch. That&rsquo;s great news, because it suggests a solution<br>to this quandary that doesn&rsquo;t require an unreasonable amount of<br>developer time.

Yeah, it wasn&rsquo;t pretty. Here&rsquo;s what was proposed:

I am proposing the following:

Keep the library soname the same as it currently is upstream. Because<br>upstream uses unversioned symbols, our package will be binary-compatible<br>with applications built against the upstream libcurl regardless of what we<br>do with symbol versioning, so leaving the soname alone minimizes the<br>amount of patching to be done against upstream code here.

Revert the Debian symbol versioning to the libcurl3 version, and make<br>libcurl.so.3 a symlink to libcurl.so.4. We have already established that<br>libcurl.so.4 is still API-compatible with libcurl.so.3, in spite of the<br>soname change upstream; reverting the symbol versioning will make it fully<br>ABI-compatible with libcurl.so.3, and adding the symlink lets<br>previously-built binaries find it.

Revert the Debian package names to the curl 7.15.5 versions. Because<br>compatibility has been restored with libcurl3 and libcurl3-gnutls,<br>restoring the package names provides the best upgrade path from etch to<br>lenny; and because the symbol versions have been reverted, the libraries<br>are not binary-compatible with the Debian packages currently named<br>libcurl4/libcurl4-gnutls/libcurl4-openssl (in spite of being<br>binary-compatible with upstream), so it would be wrong to keep the current<br>names regardless.

Drop the SSL-less variant of the library, which was not present in curl<br>7.15.5; AFAICS, there...