Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Fedora and curl-minimal
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Henrik Holst via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 17 Mar 2022 03:32:45 +0100
Den tors 17 mars 2022 kl 03:23 skrev Patrick Monnerat via curl-library <
curl-library_at_lists.haxx.se>:
>
> On 3/16/22 14:24, Kamil Dudka wrote:
> > Hi Patrick,
> Hi Kamil,
> > I presume they would remove it completely from the bare distro if it was
> > possible, but they need it to support key components of the distro: the
> > dnf installer and the abrt crash reporter. What is proposed as a
> > "minimal" version is the strict necessary to support them (BTW: they do
> > not mention the file:// protocol !).
> >
> > our packaging of curl is fully public. Here is the list of protocols
> > and features that are currently disabled in the minimal installations:
> >
> >
> https://src.fedoraproject.org/rpms/curl/blob/cd99025ff8e04abcbf1befe2c3ebefb6ad8df37f/f/curl.spec#_258
>
> Yes, I know everything is public and I'm aware of these infrastructure
> accesses being myself a Fedora packager for several years. This might
> not be the case of a lambda user (who can still curl --version of course!)
>
> What I meant is:
> https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default does not
> mention the file protocol, neither as enabled nor disabled, although
> essential to dnf/rpm.
>
> >
> > Please feel free to join the discussion about the technical details!
> No, I won't! Sorry for that, but this looks like another troll I won't
> participate to.
> >
> >> To their credit, the security argument is not the only one: they also
> >> want to reduce external packages requirements. I can understand
> >> disabling things like brotli saves some (very tiny) resources without
> >> reducing the capabilities, but removing ntlm, smb and mail protocols
> >> doesn't spare a lot with regards to the resulting tool downgrade.
> >>
> >> What will be installed by default is not a utility anymore and will
> >> just, as you noted, force real users to manually install the full
> >> version :-(
> > Sure. If users want to use something, they need to install it first.
> > This is how packaging in Linux distributions works. The fact that the
> > curl tool is available by default on all installations of Fedora is just
> > a consequence of the fact that the `rpm` package itself depends on curl.
> > Not all Linux distributions have the curl tool installed by default.
>
> What I expect from a general purpose Linux distribution is primarily to
> be an exhaustive compilation of full-featured OSS tools usable "out of
> the box": this is their main "raison d'être" as all their component
> sources are public. Being self-sufficient is not enough.
>
> I can accept to manually install some rarely used tool that is not
> already present, but not to replace an already installed one, at least
> if both versions are in the same repo. And I don't consider curl as a
> "rarely used tool"!
>
> I would also accept such a tool downgrade for embedded systems and maybe
> containers, where the resources may be low. This does not seem to be the
> Fedora primary target.
>
> If Fedora "architects" want to use a tool they do not manage, they have
> to fully provide it as such and assume its pros and cons without
> "knowing better than the users what these latter need".
>
> I love rpm/dnf and that's the main reason I'm stuck with RH/Fedora since
> RHL3. But these utilities are not a goal by themselves.
> >
> >> Regarding the security argument: we are very honest about our bugs and
> >> "advertise" them widely for the sake of our users (and I agree with
> >> this). Is it too much as it seems this plays against trust in curl in
> >> this case ? The reality is our (fixed) security flaws were far from
> >> prevalent and only a very few of them were practically exploitable.
> >>
> >> Patrick
> > This not about how curl upstream handles security issues really, which
> > I believe is really good compared to other projects. We already use
> > hardening compiler flags, SELinux, etc. to reduce potential impact of
> > security vulnerabilities.
>
> What vulnerability? Did you find one? If so, please report and let's fix
> it!
>
Another point when it comes to security is that if the version of curl
provided by the distro does not support the protocols the user needs (and
sorry for my ignorance here since I do not know if Fedora also have another
"fuller" curl package so I'm speaking in more general terms here) then many
end users will simply download the source from upstream, do the make &&
make install dance and move on, extremely few of them will ever update this
version so IMHO security becomes worse. True that the distro itself haven't
gotten worse security by this but the end result is still lots of insecure
installs.
/HH
>
> Else the "minimal" strategy won't help testing more what is considered
> by https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default as
> potentially insecure. It just reminds me a well known closed-source MUA
> that denies user access to attachments with name extension arbitrarily
> considered as insecure (like .crt for example!).
>
> > Not having installed anything that is not
> > strictly needed is just another building block of this puzzle.
> This "anything" IS needed, although not by Fedora itself. See my remark
> above about "self-sufficience". What would you think of a "minimal
> firefox" package that can only access URLs in domain "fedoraproject.org" ?
>
> One more thing: now that Fedora deprecated (and removed) the php-imap
> package, curl is the only serious alternative for accessing an MDA from
> php. A default installation with minimal package will just make it fail.
>
> In other words, I consider it brings more problems than it resolves, to
> users, sysadmins, packagers and indirectly to the curl community.
>
> Since the subject is rather out of this list scope, I will stop here !
>
> Regards,
>
> Patrick
>
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html
>
Date: Thu, 17 Mar 2022 03:32:45 +0100
Den tors 17 mars 2022 kl 03:23 skrev Patrick Monnerat via curl-library <
curl-library_at_lists.haxx.se>:
>
> On 3/16/22 14:24, Kamil Dudka wrote:
> > Hi Patrick,
> Hi Kamil,
> > I presume they would remove it completely from the bare distro if it was
> > possible, but they need it to support key components of the distro: the
> > dnf installer and the abrt crash reporter. What is proposed as a
> > "minimal" version is the strict necessary to support them (BTW: they do
> > not mention the file:// protocol !).
> >
> > our packaging of curl is fully public. Here is the list of protocols
> > and features that are currently disabled in the minimal installations:
> >
> >
> https://src.fedoraproject.org/rpms/curl/blob/cd99025ff8e04abcbf1befe2c3ebefb6ad8df37f/f/curl.spec#_258
>
> Yes, I know everything is public and I'm aware of these infrastructure
> accesses being myself a Fedora packager for several years. This might
> not be the case of a lambda user (who can still curl --version of course!)
>
> What I meant is:
> https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default does not
> mention the file protocol, neither as enabled nor disabled, although
> essential to dnf/rpm.
>
> >
> > Please feel free to join the discussion about the technical details!
> No, I won't! Sorry for that, but this looks like another troll I won't
> participate to.
> >
> >> To their credit, the security argument is not the only one: they also
> >> want to reduce external packages requirements. I can understand
> >> disabling things like brotli saves some (very tiny) resources without
> >> reducing the capabilities, but removing ntlm, smb and mail protocols
> >> doesn't spare a lot with regards to the resulting tool downgrade.
> >>
> >> What will be installed by default is not a utility anymore and will
> >> just, as you noted, force real users to manually install the full
> >> version :-(
> > Sure. If users want to use something, they need to install it first.
> > This is how packaging in Linux distributions works. The fact that the
> > curl tool is available by default on all installations of Fedora is just
> > a consequence of the fact that the `rpm` package itself depends on curl.
> > Not all Linux distributions have the curl tool installed by default.
>
> What I expect from a general purpose Linux distribution is primarily to
> be an exhaustive compilation of full-featured OSS tools usable "out of
> the box": this is their main "raison d'être" as all their component
> sources are public. Being self-sufficient is not enough.
>
> I can accept to manually install some rarely used tool that is not
> already present, but not to replace an already installed one, at least
> if both versions are in the same repo. And I don't consider curl as a
> "rarely used tool"!
>
> I would also accept such a tool downgrade for embedded systems and maybe
> containers, where the resources may be low. This does not seem to be the
> Fedora primary target.
>
> If Fedora "architects" want to use a tool they do not manage, they have
> to fully provide it as such and assume its pros and cons without
> "knowing better than the users what these latter need".
>
> I love rpm/dnf and that's the main reason I'm stuck with RH/Fedora since
> RHL3. But these utilities are not a goal by themselves.
> >
> >> Regarding the security argument: we are very honest about our bugs and
> >> "advertise" them widely for the sake of our users (and I agree with
> >> this). Is it too much as it seems this plays against trust in curl in
> >> this case ? The reality is our (fixed) security flaws were far from
> >> prevalent and only a very few of them were practically exploitable.
> >>
> >> Patrick
> > This not about how curl upstream handles security issues really, which
> > I believe is really good compared to other projects. We already use
> > hardening compiler flags, SELinux, etc. to reduce potential impact of
> > security vulnerabilities.
>
> What vulnerability? Did you find one? If so, please report and let's fix
> it!
>
Another point when it comes to security is that if the version of curl
provided by the distro does not support the protocols the user needs (and
sorry for my ignorance here since I do not know if Fedora also have another
"fuller" curl package so I'm speaking in more general terms here) then many
end users will simply download the source from upstream, do the make &&
make install dance and move on, extremely few of them will ever update this
version so IMHO security becomes worse. True that the distro itself haven't
gotten worse security by this but the end result is still lots of insecure
installs.
/HH
>
> Else the "minimal" strategy won't help testing more what is considered
> by https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default as
> potentially insecure. It just reminds me a well known closed-source MUA
> that denies user access to attachments with name extension arbitrarily
> considered as insecure (like .crt for example!).
>
> > Not having installed anything that is not
> > strictly needed is just another building block of this puzzle.
> This "anything" IS needed, although not by Fedora itself. See my remark
> above about "self-sufficience". What would you think of a "minimal
> firefox" package that can only access URLs in domain "fedoraproject.org" ?
>
> One more thing: now that Fedora deprecated (and removed) the php-imap
> package, curl is the only serious alternative for accessing an MDA from
> php. A default installation with minimal package will just make it fail.
>
> In other words, I consider it brings more problems than it resolves, to
> users, sysadmins, packagers and indirectly to the curl community.
>
> Since the subject is rather out of this list scope, I will stop here !
>
> Regards,
>
> Patrick
>
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html
>
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-03-17