Hi Kamil and everyone,
what is the plan with introduction of libcurl-minimal in Fedora? IIUC, libcurl and libcurl-minimal both have the same Provides, so libcurl-minimal can be used to satisfy automatically generated dependencies:
$ dnf repoquery --provides libcurl-minimal libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-minimal = 7.78.0-3.fc35 libcurl-minimal(x86-32) = 7.78.0-3.fc35 libcurl-minimal(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit) $ dnf repoquery --provides libcurl libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-full = 7.78.0-3.fc35 libcurl-full(x86-32) = 7.78.0-3.fc35 libcurl-full(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit)
AFAICS, no other package makes use of libcurl-{full,minimal}. In systemd we only care about a narrow subset of protocols, so libcurl-minimal is perfect. I considered adding Suggests:libcurl-minimal%{_isa} in systemd. IIUC, that'd bias dnf towards the installation of libcurl-minimal. But the problem is that if some other package expects libcurl in the full version, it'll be disappointed.
Hence my question: how to proceed with pulling in libcurl-minimal where it'd be useful? Should I just add Suggests:libcurl-minimal%{_isa} in systemd and let the maintainers of other packages add Recommends:libcurl-minimal%{_isa} or Requires:libcurl-minimal%{_isa} if they need it? What packages would that be?
Another option would be do not do any of this at package level, but instead pull in libcurl-minimal through comps or kickstart or equivalent when doing installations.
(Sorry if this is all documented somewhere… I looked around, but didn't see anything relevant.)
Zbyszek
Hi Zbyszek,
On Thursday, October 14, 2021 11:52:59 AM CEST Zbigniew Jędrzejewski-Szmek wrote:
Hi Kamil and everyone,
what is the plan with introduction of libcurl-minimal in Fedora?
I proposed to use libcurl-minimal and curl-minimal in minimal base images half a year ago but there has been no reply so far:
https://pagure.io/minimization/issue/25
IIUC, libcurl and libcurl-minimal both have the same Provides, so libcurl-minimal can be used to satisfy automatically generated dependencies:
$ dnf repoquery --provides libcurl-minimal libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-minimal = 7.78.0-3.fc35 libcurl-minimal(x86-32) = 7.78.0-3.fc35 libcurl-minimal(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit) $ dnf repoquery --provides libcurl libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-full = 7.78.0-3.fc35 libcurl-full(x86-32) = 7.78.0-3.fc35 libcurl-full(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit)
AFAICS, no other package makes use of libcurl-{full,minimal}. In systemd we only care about a narrow subset of protocols, so libcurl-minimal is perfect. I considered adding Suggests:libcurl-minimal%{_isa} in systemd. IIUC, that'd bias dnf towards the installation of libcurl-minimal. But the problem is that if some other package expects libcurl in the full version, it'll be disappointed.
If a package (strictly) requires libcurl-full, it should probably have an explicit dependency for it. If some packages require implementation of a specific protocol or feature, we could introduce virtual provides for them, too, to make the sets of protocols/features in the -minimal variants less hard-coded.
Hence my question: how to proceed with pulling in libcurl-minimal where it'd be useful? Should I just add Suggests:libcurl-minimal%{_isa} in systemd and let the maintainers of other packages add Recommends:libcurl-minimal%{_isa} or Requires:libcurl-minimal%{_isa} if they need it? What packages would that be? Another option would be do not do any of this at package level, but instead pull in libcurl-minimal through comps or kickstart or equivalent when doing installations.
This is more a question for users of (lib)curl. I do not have any strong opinion on that.
Kamil
(Sorry if this is all documented somewhere… I looked around, but didn't see anything relevant.)
Zbyszek
Hello,
On Thursday, October 14, 2021 6:51:54 AM EDT Kamil Dudka wrote:
what is the plan with introduction of libcurl-minimal in Fedora?
I proposed to use libcurl-minimal and curl-minimal in minimal base images half a year ago but there has been no reply so far:
https://pagure.io/minimization/issue/25
I'd like to suggest making libcurl-minimal very minimal for security reasons. The main curl package has many security issues (CVE's) constantly. But usually, the problem is in some obscure feature/protocol. Looking at the packages that depend on libcurl with rpmreaper, most would use http(s). There might be some that use another protocol. But clear text protocols like telnet and ftp really don't have a use in today's internet. Too many threats for clear text.
So with security in mind - and not solving excessive dependencies, I'd suggest going very minimal. Just maybe 3 or 4 of the most used protocols by things that require libcurl.
Cheers, -Steve
On Thursday, October 14, 2021 3:27:03 PM CEST Steve Grubb wrote:
Hello,
On Thursday, October 14, 2021 6:51:54 AM EDT Kamil Dudka wrote:
what is the plan with introduction of libcurl-minimal in Fedora?
I proposed to use libcurl-minimal and curl-minimal in minimal base images
half a year ago but there has been no reply so far: https://pagure.io/minimization/issue/25
I'd like to suggest making libcurl-minimal very minimal for security reasons. The main curl package has many security issues (CVE's) constantly. But usually, the problem is in some obscure feature/protocol. Looking at the packages that depend on libcurl with rpmreaper, most would use http(s). There might be some that use another protocol. But clear text protocols like telnet and ftp really don't have a use in today's internet. Too many threats for clear text.
So with security in mind - and not solving excessive dependencies, I'd suggest going very minimal. Just maybe 3 or 4 of the most used protocols by things that require libcurl.
Cheers, -Steve
Hi Steve,
this is exactly what the following bug (filed by Jan Pazdziora) is about:
https://bugzilla.redhat.com/2005874
The changes proposed in the above bug have already landed into Fedora Rawhide.
As I understand it, Zbyszek is now proposing to make changes to other packages and/or distribution metadata in order to make (lib)curl-minimal actually used on some Fedora installations by default.
Kamil
Hi,
On Thu, 2021-10-14 at 16:49 +0200, Kamil Dudka wrote:
As I understand it, Zbyszek is now proposing to make changes to other packages and/or distribution metadata in order to make (lib)curl-minimal actually used on some Fedora installations by default.
This sounds interesting. For elfutils-debuginfod-client we really only support http(s):// and file:// so replacing our dependency from full libcurl to libcurl-minimal seems a good idea (assuming those 3 protocols are in libcurl-minimal). Please let us know what we should do/test to see if this works as intended.
Thanks,
Mark
On Friday, October 15, 2021 12:47:44 PM CEST Mark Wielaard wrote:
Hi,
On Thu, 2021-10-14 at 16:49 +0200, Kamil Dudka wrote:
As I understand it, Zbyszek is now proposing to make changes to other packages and/or distribution metadata in order to make (lib)curl-minimal actually used on some Fedora installations by default.
This sounds interesting. For elfutils-debuginfod-client we really only support http(s):// and file:// so replacing our dependency from full libcurl to libcurl-minimal seems a good idea (assuming those 3 protocols are in libcurl-minimal). Please let us know what we should do/test to see if this works as intended.
I think that no changes are needed in the elfutils-debuginfod-client package for now. libcurl-minimal provides libcurl, so you should be able to simply swap the packages and use libcurl-minimal with elfutils-debuginfod-client:
# yum install --allowerasing libcurl-minimal
Actually, putting a strict requirement on libcurl-minimal to any package would be counterproductive because it would prevent users from "upgrading" to libcurl-full.
We would rather need it the other way around -- explicitly tag the packages that would *not* work properly with libcurl-minimal for some reason.
Kamil
Thanks,
Mark
On Fri, Oct 15, 2021 at 12:47:44PM +0200, Mark Wielaard wrote:
Hi,
On Thu, 2021-10-14 at 16:49 +0200, Kamil Dudka wrote:
As I understand it, Zbyszek is now proposing to make changes to other packages and/or distribution metadata in order to make (lib)curl-minimal actually used on some Fedora installations by default.
This sounds interesting. For elfutils-debuginfod-client we really only support http(s):// and file:// so replacing our dependency from full libcurl to libcurl-minimal seems a good idea (assuming those 3 protocols are in libcurl-minimal). Please let us know what we should do/test to see if this works as intended.
You should also probably do: curl_easy_setopt(c, CURLOPT_PROTOCOLS, CURLPROTO_HTTPS|CURLPROTO_FILE) (copied from https://github.com/systemd/systemd/commit/55b90ee00b).
Zbyszek
Steve Grubb wrote:
I'd like to suggest making libcurl-minimal very minimal for security reasons. The main curl package has many security issues (CVE's) constantly. But usually, the problem is in some obscure feature/protocol. Looking at the packages that depend on libcurl with rpmreaper, most would use http(s). There might be some that use another protocol. But clear text protocols like telnet and ftp really don't have a use in today's internet. Too many threats for clear text.
I suspect that disabling FTP in libcurl is going to break a lot of stuff.
Kevin Kofler
On Sat, Oct 16, 2021 at 10:08 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
Steve Grubb wrote:
I'd like to suggest making libcurl-minimal very minimal for security reasons. The main curl package has many security issues (CVE's) constantly. But usually, the problem is in some obscure feature/protocol. Looking at the packages that depend on libcurl with rpmreaper, most would use http(s). There might be some that use another protocol. But clear
text
protocols like telnet and ftp really don't have a use in today's
internet.
Too many threats for clear text.
I suspect that disabling FTP in libcurl is going to break a lot of stuff.
I'd be curious, what package uses curl for it's FTP support?
-Steve
On Sunday, October 17, 2021 2:40:05 PM CEST Steven Grubb wrote:
On Sat, Oct 16, 2021 at 10:08 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
Steve Grubb wrote:
I'd like to suggest making libcurl-minimal very minimal for security reasons. The main curl package has many security issues (CVE's) constantly. But usually, the problem is in some obscure feature/protocol. Looking at the packages that depend on libcurl with rpmreaper, most would use http(s). There might be some that use another protocol. But clear
text
protocols like telnet and ftp really don't have a use in today's
internet.
Too many threats for clear text.
I suspect that disabling FTP in libcurl is going to break a lot of stuff.
I'd be curious, what package uses curl for it's FTP support?
-Steve
For example dracut, dnf, and rpm seem to use FTP:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-l... https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L63... https://github.com/rpm-software-management/rpm/blob/rpm-4.14.0-release/rpmio...
Kamil
On Mon, Oct 18, 2021 at 10:33:59AM +0200, Kamil Dudka wrote:
For example dracut, dnf, and rpm seem to use FTP:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55
Here dracut allows ftp://, by calling curl. If curl does not support the protocol, this will fail… I think this is what we want.
(BTW, I think the dracut repo on git.kernel.org seems stale… https://github.com/dracutdevs/dracut has commits from this week, but kernel.org ends at 2021-05-27.)
https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636
I think the story would be the same here: if an url with ftp:// was actually configured somewhere, the download would fail. But I don't think we have many such urls...
https://github.com/rpm-software-management/rpm/blob/rpm-4.14.0-release/rpmio/url.c#L25
This calls %_urlhelper, i.e. '/usr/bin/curl --silent --show-error --fail --globoff --location -o', so it will fail on ftp://.
Anyway, with current libcurl-minimal, dnf and rpm both seem to download ftp:// urls just fine… (I used [2] for testing since we don't advertise ftp anywhere.)
--
To move this along, I pushed Suggests:libcurl-minimal to systemd-journal-remote and systemd-container [1], because those two systemd subpackages Require libcurl.so.4. This saves 5MB (out of 105MB) when installing systemd-journal-remote into an empty chroot. But those two subpackages are optional so we might get full libcurl when something else pulls it in… I think it'd make sense to do this at some lower level so that we always get libcurl-minimal by default.
If we added Suggests:libcurl-minimal in filesystem.rpm, it'd be prefered everywhere. But we might also get libcurl-minimal if somebody installs filesystem.rpm with weak dependencies, which we don't want. So I think this should be only added in packages that actually pull in libcurl. But I don't see any great candidate, since none of the low-level packages use libcurl.
[1] https://src.fedoraproject.org/rpms/systemd/c/2731a22179be6db678bde386ae3f931... [2] ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/24/Everything/armhfp/os/Packages/p/python3-custodia-0.1.0-3.fc24.noarch.rpm
Zbyszek
On Thu, Feb 10, 2022 at 12:59 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Oct 18, 2021 at 10:33:59AM +0200, Kamil Dudka wrote:
For example dracut, dnf, and rpm seem to use FTP:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55Here dracut allows ftp://, by calling curl. If curl does not support the protocol, this will fail… I think this is what we want.
(BTW, I think the dracut repo on git.kernel.org seems stale… https://github.com/dracutdevs/dracut has commits from this week, but kernel.org ends at 2021-05-27.)
https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636I think the story would be the same here: if an url with ftp:// was actually configured somewhere, the download would fail. But I don't think we have many such urls...
https://github.com/rpm-software-management/rpm/blob/rpm-4.14.0-release/rpmio/url.c#L25This calls %_urlhelper, i.e. '/usr/bin/curl --silent --show-error --fail --globoff --location -o', so it will fail on ftp://.
Anyway, with current libcurl-minimal, dnf and rpm both seem to download ftp:// urls just fine… (I used [2] for testing since we don't advertise ftp anywhere.)
--
To move this along, I pushed Suggests:libcurl-minimal to systemd-journal-remote and systemd-container [1], because those two systemd subpackages Require libcurl.so.4. This saves 5MB (out of 105MB) when installing systemd-journal-remote into an empty chroot. But those two subpackages are optional so we might get full libcurl when something else pulls it in… I think it'd make sense to do this at some lower level so that we always get libcurl-minimal by default.
If we added Suggests:libcurl-minimal in filesystem.rpm, it'd be prefered everywhere. But we might also get libcurl-minimal if somebody installs filesystem.rpm with weak dependencies, which we don't want. So I think this should be only added in packages that actually pull in libcurl. But I don't see any great candidate, since none of the low-level packages use libcurl.
This is a bad idea because it creates a crappy user experience when someone wants the full curl.
If an environment should use the minimal one, the environment creator should explicitly set it. Minimal packages should *not* be in the default package selection.
On Thu, Feb 10, 2022 at 01:09:06PM -0500, Neal Gompa wrote:
On Thu, Feb 10, 2022 at 12:59 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Oct 18, 2021 at 10:33:59AM +0200, Kamil Dudka wrote:
For example dracut, dnf, and rpm seem to use FTP:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55Here dracut allows ftp://, by calling curl. If curl does not support the protocol, this will fail… I think this is what we want.
(BTW, I think the dracut repo on git.kernel.org seems stale… https://github.com/dracutdevs/dracut has commits from this week, but kernel.org ends at 2021-05-27.)
https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636I think the story would be the same here: if an url with ftp:// was actually configured somewhere, the download would fail. But I don't think we have many such urls...
https://github.com/rpm-software-management/rpm/blob/rpm-4.14.0-release/rpmio/url.c#L25This calls %_urlhelper, i.e. '/usr/bin/curl --silent --show-error --fail --globoff --location -o', so it will fail on ftp://.
Anyway, with current libcurl-minimal, dnf and rpm both seem to download ftp:// urls just fine… (I used [2] for testing since we don't advertise ftp anywhere.)
--
To move this along, I pushed Suggests:libcurl-minimal to systemd-journal-remote and systemd-container [1], because those two systemd subpackages Require libcurl.so.4. This saves 5MB (out of 105MB) when installing systemd-journal-remote into an empty chroot. But those two subpackages are optional so we might get full libcurl when something else pulls it in… I think it'd make sense to do this at some lower level so that we always get libcurl-minimal by default.
If we added Suggests:libcurl-minimal in filesystem.rpm, it'd be prefered everywhere. But we might also get libcurl-minimal if somebody installs filesystem.rpm with weak dependencies, which we don't want. So I think this should be only added in packages that actually pull in libcurl. But I don't see any great candidate, since none of the low-level packages use libcurl.
This is a bad idea because it creates a crappy user experience when someone wants the full curl.
I don't think so. If you want the full set of protocols, just pull in curl-full. I'm pretty sure that 99.5% of people will not notice, because they use curl with URLs that are actually available, which nowadays is primarily https://.
If an environment should use the minimal one, the environment creator should explicitly set it. Minimal packages should *not* be in the default package selection.
... or the reverse: when libcurl is pulled in as a dependency, pull in the smaller version. This makes sense especially with the recommended practice of limiting supported protocols with curl_setopt() internally in the application. In the (unlikely) scenario that people need telnet:// and dict://, they can request curl-full(*).
(*) I'm assuming that other rpms that need those protocols from libcurl, will pull in the full libcurl too. Some packaging adjustments might be needed. So this is only about using strange protocols directly from /usr/bin/curl or such.
I now filed https://src.fedoraproject.org/rpms/curl/pull-request/12 and https://src.fedoraproject.org/rpms/rpm/pull-request/22. With #12 curl-minimal prefers libcurl-minimal, and with #22, rpm prefers curl-minimal over curl. This should achieve the desired effect on most installations.
Zbyszek
On Thu, 2022-02-10 at 19:30 +0100, Zbigniew Jędrzejewski-Szmek wrote:
(*) I'm assuming that other rpms that need those protocols from libcurl, will pull in the full libcurl too. Some packaging adjustments might be needed. So this is only about using strange protocols directly from /usr/bin/curl or such.
Then this should probably be done as a Change with proper notification. If the effect is that an automatic dependency on libcurl is now likely to be satisfied by a much more minimal implementation with fewer capabilities and the depending app may not expect that, a random devel@ thread does not seem like enough notification.
On Thu, Feb 10, 2022 at 10:41:41AM -0800, Adam Williamson wrote:
On Thu, 2022-02-10 at 19:30 +0100, Zbigniew Jędrzejewski-Szmek wrote:
(*) I'm assuming that other rpms that need those protocols from libcurl, will pull in the full libcurl too. Some packaging adjustments might be needed. So this is only about using strange protocols directly from /usr/bin/curl or such.
Then this should probably be done as a Change with proper notification. If the effect is that an automatic dependency on libcurl is now likely to be satisfied by a much more minimal implementation with fewer capabilities and the depending app may not expect that, a random devel@ thread does not seem like enough notification.
That's a good idea. I'll file a late Change page for F36.
Zbyszek
On Thu, Feb 10, 2022 at 2:51 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
That's a good idea. I'll file a late Change page for F36.
We're deep enough into the cycle that sending a proposal through the process, even superficially, seems excessive. I suggest just sending a devel-announce post or waiting to implement it until F37.
On Thu, Feb 10, 2022, 3:44 PM Ben Cotton bcotton@redhat.com wrote:
On Thu, Feb 10, 2022 at 2:51 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
That's a good idea. I'll file a late Change page for F36.
We're deep enough into the cycle that sending a proposal through the process, even superficially, seems excessive. I suggest just sending a devel-announce post or waiting to implement it until F37.
I'd prefer to see this as an F37 Change.
On Thu, 2022-02-10 at 18:58 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 18, 2021 at 10:33:59AM +0200, Kamil Dudka wrote:
For example dracut, dnf, and rpm seem to use FTP:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55Here dracut allows ftp://, by calling curl. If curl does not support the protocol, this will fail… I think this is what we want.
(BTW, I think the dracut repo on git.kernel.org seems stale… https://github.com/dracutdevs/dracut has commits from this week, but kernel.org ends at 2021-05-27.)
https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636I think the story would be the same here: if an url with ftp:// was actually configured somewhere, the download would fail. But I don't think we have many such urls...
We aren't the only ones who set up repositories. Organizations which run Fedora and RHEL often have internal repositories, which may use FTP.
On Thu, Feb 10, 2022 at 10:39:38AM -0800, Adam Williamson wrote:
On Thu, 2022-02-10 at 18:58 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 18, 2021 at 10:33:59AM +0200, Kamil Dudka wrote:
For example dracut, dnf, and rpm seem to use FTP:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55Here dracut allows ftp://, by calling curl. If curl does not support the protocol, this will fail… I think this is what we want.
(BTW, I think the dracut repo on git.kernel.org seems stale… https://github.com/dracutdevs/dracut has commits from this week, but kernel.org ends at 2021-05-27.)
https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636I think the story would be the same here: if an url with ftp:// was actually configured somewhere, the download would fail. But I don't think we have many such urls...
We aren't the only ones who set up repositories. Organizations which run Fedora and RHEL often have internal repositories, which may use FTP.
To clarify: ftp still works, even with the changes in flight. The discussion about dropping ftp was mostly theoretical. AFAIK, curl maintainers don't plan to do this atm.
Zbyszek
On 2/10/22 13:39, Adam Williamson wrote:
On Thu, 2022-02-10 at 18:58 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 18, 2021 at 10:33:59AM +0200, Kamil Dudka wrote:
For example dracut, dnf, and rpm seem to use FTP:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55Here dracut allows ftp://, by calling curl. If curl does not support the protocol, this will fail… I think this is what we want.
(BTW, I think the dracut repo on git.kernel.org seems stale… https://github.com/dracutdevs/dracut has commits from this week, but kernel.org ends at 2021-05-27.)
https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636I think the story would be the same here: if an url with ftp:// was actually configured somewhere, the download would fail. But I don't think we have many such urls...
We aren't the only ones who set up repositories. Organizations which run Fedora and RHEL often have internal repositories, which may use FTP.
Could we add a warning that FTP is deprecated?
On 2/10/22 18:49, Demi Marie Obenour wrote:
On 2/10/22 13:39, Adam Williamson wrote:
On Thu, 2022-02-10 at 18:58 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 18, 2021 at 10:33:59AM +0200, Kamil Dudka wrote:
For example dracut, dnf, and rpm seem to use FTP:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55Here dracut allows ftp://, by calling curl. If curl does not support the protocol, this will fail… I think this is what we want.
(BTW, I think the dracut repo on git.kernel.org seems stale… https://github.com/dracutdevs/dracut has commits from this week, but kernel.org ends at 2021-05-27.)
https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636I think the story would be the same here: if an url with ftp:// was actually configured somewhere, the download would fail. But I don't think we have many such urls...
We aren't the only ones who set up repositories. Organizations which run Fedora and RHEL often have internal repositories, which may use FTP.
Could we add a warning that FTP is deprecated?
To be clear: this is for dracut and DNF, not in general. And it might be a bad idea even in those cases.
On Thu, Feb 10, 2022 at 6:56 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 2/10/22 18:49, Demi Marie Obenour wrote:
On 2/10/22 13:39, Adam Williamson wrote:
On Thu, 2022-02-10 at 18:58 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 18, 2021 at 10:33:59AM +0200, Kamil Dudka wrote:
For example dracut, dnf, and rpm seem to use FTP:
https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/45url-lib/url-lib.sh?h=055#n55Here dracut allows ftp://, by calling curl. If curl does not support the protocol, this will fail… I think this is what we want.
(BTW, I think the dracut repo on git.kernel.org seems stale… https://github.com/dracutdevs/dracut has commits from this week, but kernel.org ends at 2021-05-27.)
https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#L636I think the story would be the same here: if an url with ftp:// was actually configured somewhere, the download would fail. But I don't think we have many such urls...
We aren't the only ones who set up repositories. Organizations which run Fedora and RHEL often have internal repositories, which may use FTP.
Could we add a warning that FTP is deprecated?
To be clear: this is for dracut and DNF, not in general. And it might be a bad idea even in those cases.
That would only be something we could do if it was true. And it's not. So we wouldn't reasonably do that.
On Thu, Oct 14, 2021 at 09:52:59AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Hi Kamil and everyone,
what is the plan with introduction of libcurl-minimal in Fedora? IIUC, libcurl and libcurl-minimal both have the same Provides, so libcurl-minimal can be used to satisfy automatically generated dependencies:
$ dnf repoquery --provides libcurl-minimal libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-minimal = 7.78.0-3.fc35 libcurl-minimal(x86-32) = 7.78.0-3.fc35 libcurl-minimal(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit) $ dnf repoquery --provides libcurl libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-full = 7.78.0-3.fc35 libcurl-full(x86-32) = 7.78.0-3.fc35 libcurl-full(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit)
What's the aim here? Small size on disk? General fear of having insecure but unused protocols linked with programs?
It's a shame it has to be packaged this way. I got half way through writing a curl handler (which I really must finish) and my impression is that at a code level they 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.
In the meantime I'd like to encourage every program in Fedora that uses curl to call CURLOPT_PROTOCOLS(3). This is a real defence against remote exploits (CVE-2013-0249 was one that happened in qemu).
Rich.
On Saturday, October 16, 2021 5:32:17 PM CEST Richard W.M. Jones wrote:
On Thu, Oct 14, 2021 at 09:52:59AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Hi Kamil and everyone,
what is the plan with introduction of libcurl-minimal in Fedora? IIUC, libcurl and libcurl-minimal both have the same Provides, so libcurl-minimal can be used to satisfy automatically generated dependencies:
$ dnf repoquery --provides libcurl-minimal libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-minimal = 7.78.0-3.fc35 libcurl-minimal(x86-32) = 7.78.0-3.fc35 libcurl-minimal(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit) $ dnf repoquery --provides libcurl libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-full = 7.78.0-3.fc35 libcurl-full(x86-32) = 7.78.0-3.fc35 libcurl-full(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit)
What's the aim here? Small size on disk? General fear of having insecure but unused protocols linked with programs?
Both. The size reduction is, of course, more significant when you count the libraries that are directly or indirectly pulled in by the rarely used protocols or features of (lib)curl.
The decision whether a security issue applies to a certain deployment is often not driven by experts with deep technical knowledge of projects like curl. An argument that a protocol is normally not used by a program, or that the protocol is disabled on almost all code paths, may appear less compelling to the decision makers than if the code in question was simply not compiled in.
It's a shame it has to be packaged this way. I got half way through writing a curl handler (which I really must finish) and my impression is that at a code level they 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.
That might be an alternative with all its pros and cons. But it is simply not available now and nobody is working on it, as far as I know.
In the meantime I'd like to encourage every program in Fedora that uses curl to call CURLOPT_PROTOCOLS(3). This is a real defence against remote exploits (CVE-2013-0249 was one that happened in qemu).
Yes, that makes sense.
Kamil
Rich.
-
Adam Williamson -
Ben Cotton -
Demi Marie Obenour -
Kamil Dudka -
Kevin Kofler -
Mark Wielaard -
Neal Gompa -
Richard W.M. Jones -
Steve Grubb -
Steven Grubb
-
Zbigniew Jędrzejewski-Szmek