On Tue, Feb 22, 2022 at 05:09:37PM +0000, Daniel P. Berrangé wrote: > On Tue, Feb 22, 2022 at 12:00:06PM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default > > > > == Summary == > > `libcurl-minimal` and `curl-minimal` will be installed by default > > instead of `libcurl` and `curl`. > > The "minimal" variants provide only a subset of protocols (HTTP, HTTPS, FTP). > > The full versions can be explicitly requested as `libcurl-full` and `curl-full`. > > > > == Owner == > > * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] > > * Email: zbyszek at in.waw.pl > > * Name: [[User:Kdudka| Kamil Dudka]] > > * Email: kdudka at redhat.com > > > > > > == Detailed Description == > > > > The `curl` package provides two sets of subpackages: `curl`+`libcurl` > > and `curl-minimal`+`libcurl+minimal`. > > `curl-minimal`+`libcurl-minimal` 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. > > > > (Both variants support HTTP, HTTPS, and FTP.) > > > > `curl-minimal` has `Provides:curl` and `libcurl-minimal` has `Provides:libcurl`. > > This means that both sets can be used to satisfy a dependency on > > `curl` or `libcurl`. > > `curl` has the virtual `Provides:curl-full` and `libcurl` has the > > virtual `Provides:libcurl-full`. > > The user or another package can explicitly pull in the full variants, > > e.g. with `dnf install curl-full` > > or `Requires: libcurl-full`. > > With this change, `Suggests: libcurl-minimal` or `Suggests: > > curl-minimal` will be added to a few packages > > that already have a dependency on `libcurl` or `curl`. > > Currently, doing this for `systemd` and `rpm` is planned. > > Effectively, `dnf` will install the minimal variants, unless another > > package has a stronger dependency on the full variants. > > > > > > == Benefit to Fedora == > > There are two separate motivations for this. > > > > Those infrequently used protocols are less tested than the common ones > > and are a source of security bugs. > > Most users are not using those protocols anyway, so disabling them > > reduces the bug and attack surface. > > (In fact, many applications already call `curl_easy_setopt(c, > > CURLOPT_PROTOCOLS, …)` to internally > > limit what protocols are supported. So even if `libcurl` is swapped > > for `libcurl-minimal` for many > > uses this will not be a difference.) > > > > The packages for the minimal variants are smaller: > > a trivial installation with `curl-minimal`+`libcurl+minimal` is 18 MB > > download, 57 MB installed size, 50 packages; > > the same with `curl-full` and `libcurl-full` is 21 MB download, 65 > > installed size, 62 packages. > > Thus we save 8 MB, reducing the initial size by 12%. > > > > == Scope == > > * Proposal owners: > > Create pull requests to add `Suggests: curl-minimal` or `Suggests: > > libcurl-minimal` as appropriate > > to packages which already require `curl` or `libcurl`: `rpm` and `systemd`. > > This means that any installation (which should be most of them) will > > get the minimal variants. > > > > * Other developers: > > For packages that use the full variants: add `Recommends: curl-full` > > or `Recommends: libcurl-full` or > > `Requires: curl-full` or `Requires: libcurl-full` as appropriate. > > The libcurl-devel RPM has a Requires: libcurl, which will > be satisfied by either full or minimal versions. > > IOW, if an application has a test suite that relies on a > particular protocols not present in the minimal build, then > their BuildRequires will also need to explicitly ask for a > libcurl-full. I added a note in "Upgrade/compatibility impact". If this turns out to be common problem, we could add Requires:libcurl-full to libcurl-devel. Nevertheless, I don't expect that that it will be common at all. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
