4:52 a.m.
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
5:51 a.m.
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
8:27 a.m.
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
9:49 a.m.
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
5:47 a.m.
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
6:29 a.m.
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
7:57 a.m.
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
9:06 p.m.
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
7:40 a.m.
On Sat, Oct 16, 2021 at 10:08 PM Kevin Kofler via devel <
devel(a)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
3:33 a.m.
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(a)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/45ur...
https://github.com/rpm-software-management/dnf/blob/f85cf313/dnf/repo.py#...
https://github.com/rpm-software-management/rpm/blob/rpm-4.14.0-release/rp...
Kamil
11:58 a.m.
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/45ur...
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.)
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...
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/2731a22179be6db678bde386ae3f...
[2]
ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/release...
Zbyszek
12:09 p.m.
On Thu, Feb 10, 2022 at 12:59 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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/45ur...
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#...
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/rp...
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.
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.
--
真実はいつも一つ！/ Always, there's only one truth!
12:30 p.m.
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(a)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/45ur...
> 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#...
> 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/rp...
> 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.
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
12:41 p.m.
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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1:50 p.m.
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
2:43 p.m.
On Thu, Feb 10, 2022 at 2:51 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2:47 p.m.
On Thu, Feb 10, 2022, 3:44 PM Ben Cotton <bcotton(a)redhat.com> wrote:
On Thu, Feb 10, 2022 at 2:51 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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.
12:39 p.m.
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/45ur...
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#...
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...
We aren't the only ones who set up repositories. Organizations which
run Fedora and RHEL often have internal repositories, which may use
FTP.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1:49 p.m.
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/45ur...
> 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#...
> 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...
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
5:49 p.m.
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/45ur...
> 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#...
> 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...
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?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
5:56 p.m.
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/45ur...
>> 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#...
>> 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...
>
> 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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
5:59 p.m.
On Thu, Feb 10, 2022 at 6:56 PM Demi Marie Obenour
<demiobenour(a)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/45ur...
>>> 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#...
>>> 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...
>>
>> 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.
--
真実はいつも一つ！/ Always, there's only one truth!
10:32 a.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
7:19 a.m.
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.
805
days inactive
924
days old
23 comments
11 participants
participants (11)
-
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