Fedora considers curl-minimal

The curl utility is a command-line program (and associated library) for interacting with various network protocols; it is commonly used to do things like transferring data from a remote server over HTTP or HTTPS using a URL. But curl also supports a lot more protocols, some of which are probably rarely used, obsolete, deprecated, or all three. As a recent discussion on the Fedora devel mailing list shows, though, it is hard to find agreement that support for only some of those protocols should be installed by default, while others might be left in an optional package for those who need them.

A proposal to install a minimal version of curl by default starting with Fedora 37 was posted to the list on February 22. As is usual for feature proposals, it was posted on behalf of the feature owners, Zbigniew Jędrzejewski-Szmek and Kamil Dudka, by Fedora program manager Ben Cotton. The idea is to make the curl-minimal package (and it companion libcurl-minimal) the default for installation on Fedora systems, while allowing users to switch to the full curl package (and libcurl) if they need it. The minimal variants "are compiled with various semi-obsolete protocols and infrequently-used features disabled: DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP, SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names", while both packages support HTTP, HTTPS, and FTP.

There are two benefits for Fedora described in the proposal. The infrequently used protocols are not as well tested as the others and "are a source of security bugs". Most people are not using them anyway, so removing them reduces the attack surface for the default installation. In addition, the minimal packages are smaller, saving 8MB, which is a reduction of 12%.

The problem with having "extra" protocols available for curl is that they might be invoked unexpectedly. Even if a program is using a URL with an http scheme (i.e. protocol), the (possibly malicious) server could redirect to a different URL with a different protocol entirely, which would then invoke that code in curl if it is present. In addition, if user input is used for the URL, it could refer to an unexpected protocol, which curl will happily try to satisfy. Thus protocols that are installed, but not actually needed, increase the potential attack surface of the distribution.

IDN

Removing support for internationalized domain name (IDN) handling could be a problem even for those who only need the three protocols available in curl-minimal, Björn Persson said. IDN domain names are internationalized names in Unicode that have been encoded into ASCII using Punycode. That is so that they can be used in the Domain Name System (DNS), which in practice can only handle a subset of ASCII in domain names. The lack of support for IDN "makes libcurl-minimal suited only for programs that only communicate with a predefined set of servers in ASCII-only domains".

Jędrzejewski-Szmek wondered how many domains actually use IDN, noting that he had added support for it to systemd, but "realized that I have _never_ once used an idn domain outside of testing". He also pointed out that this change would not affect other programs, like web browsers, where IDN use might be more prevalent. Others in the thread thought that IDN support was a must, at least for certain regions of the world. Dudka said he was not necessarily opposed to adding IDN support to curl-minimal, but that it had been removed from the universal base image (UBI) for the ubi9 container images "and nobody has complained about it so far". It is not clear how much exposure ubi9 images have actually gotten at this point, however.

The question of the prevalence of IDN domains was at least partly answered by Jędrzejewski-Szmek himself; there are more in use than he expected. He would be in favor of adding IDN support to curl-minimal "_if_ there are people who'd actually use this for real". Persson noted that there are multiple programs that have incomplete support for IDN, including OpenSSH, Nmap, and the BIND utilities, but that is a "problem that you're about to make worse". Having a default curl without such support will "end up hampering the adoption of international domains even more". Dudka said that since there is a demand for it, he had created a pull request to add IDN in libcurl-minimal.

Security benefit

Chris Adams thought that the security benefit of not shipping the other protocols was a "poor argument". If those protocols are still going to be available, "they need to be maintained to the same level". Beyond that, most of the security problems reported for curl seem to be in the protocols that would be retained:

Looking at the curl RPM changelog on F35, most CVE entries seem to be TLS and/or HTTP(S) related, with a couple of TELNET and one MQTT. Looking back to 2020, there were more TLS and a couple of FTP (which is staying in the minimal build).

If TELNET/etc. is a problem and not being maintained upstream, then just drop TELNET. Don't shuffle it off to the side and ignore security issues in a package still in the repos.

But Demi Marie Obenour disagreed; the purpose of the change is not to reduce the maintenance burden, but to reduce the impact of vulnerabilities in the less-used parts of curl. "Right now, a vulnerability in an obscure protocol impacts most users. With this change, it will only impact users that have installed the full version of curl." But Adams said that using security concerns as a justification for the change was not reasonable. If the code is prone to security problems, Fedora should not be shipping it at all. In a followup message, Obenour said that the change is about the attack surface: "Secure enough to ship ≠ secure enough to enable by default."

Peter Robinson asked about removing FTP as well, "with most browsers obsoleting the protocol due to lack of security". Dudka thought that was premature, but suggested that the day was coming: "it may happen that FTP will be unavailable by default in a year or two".

Richard W.M. Jones thought a different approach was in order. While the minimal variants are smaller, that is "a non-goal for almost everyone". Beyond that, the security benefit "will be immediately negated once everyone unbreaks their Fedora by installing curl-full". He suggested that libcurl-using Fedora packages should use the CURLOPT_PROTOCOLS option to only allow the protocols they expect. In a message back in October, he said that instead of creating a single minimal version of curl, a more fine-grained approach could be pursued:

[...] my impression is that at a code level they [the protocols] are quite modular, so maybe upstream would be interested in turning them into real loadable modules. Then we could package each protocol ("curl-http.so") as a separate RPM which is really best of all worlds.

Dudka was in favor of using CURLOPT_PROTOCOLS for Fedora packages that use curl, "but it cannot be a replacement for libcurl-minimal because there is no algorithmic way to decide whether all users of libcurl disable a problematic protocol on all reachable code paths". The switch to minimal is not just for container images, where the installation footprint needs to be as small as possible, as Jones had suggested, because there are other (unspecified) Fedora installations where the size is also important. Dudka also reiterated the attack-surface reduction as a benefit for those who do not need any of the extras.

Jones mentioned the modularization of curl again, but said "I think this whole business of minimizing Fedora is getting way out of hand". Dudka said that it had been added as a wishlist item for curl, "but I do not remember anybody working on it". Neal Gompa agreed with Jones that defaulting to a curl-minimal, instead of taking a modular approach, would cause more problems than it would solve, at least for many Fedora users:

This is a very big hammer that basically tells people that we're crippling curl by default for users and it has very large network effects across the entire distribution. It's quite one thing to use curl-minimal for containers where people expect tools to be broken in the endless pursuit of smaller base images, but when real people need to use real systems in complex configurations, having a reduced functionality curl by default is just going to lead to support nightmares and complaints about random breakages in applications on Fedora.

FESCo

After the mailing list discussion died down, inconclusively, the Fedora Engineering Steering Committee (FESCo) took up the proposal at its March 8 meeting (minutes, IRC log at the point it was discussed). After some discussion, much of it about the upgrade path for users who do want the full curl, the proposal was unanimously rejected as it stands, with an invitation to bring it back with some changes. It turns out that switching from the default curl-minimal to curl would not be done with the expected "dnf install" command or similar, but would need to use the less well-known "dnf swap" command. That was deemed confusing and surprising to users, so part of any re-submission will be changing the way the split into two packages was made.

In addition, some of the arguments for and against the benefit with respect to security concerns for the "extra" protocols were aired, but not resolved there either. It is not clear whether simply changing the packaging approach will be enough to get the feature over the line or not. To some, the overall benefit is low, while user confusion is clearly a possible outcome. The need for the feature to be the default distribution-wide seems unclear, as well; having container images and the like default to curl-minimal, while leaving other Fedora editions with the full curl package by default, might be a kind of middle ground.

Curl is used in lots of different ways within scripts and programs of various kinds, including in dnf itself. Since the curl upstream has not taken the modular approach, at least yet, any kind of attack-surface reduction for curl in Fedora is going to require this kind of "big hammer", where many of the protocols are shunted aside. It does seem like it leaves open the possibility of having to squeeze a few more protocols or features into curl-minimal, as with IDN support, if it is realized they are actually widely needed. For now, at least, curl-minimal will not become the default for Fedora 37, however.