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: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 17 Mar 2022 03:23:22 +0100
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!
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
Date: Thu, 17 Mar 2022 03:23:22 +0100
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!
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.htmlReceived on 2022-03-17