On Fri, Feb 25, 2022 at 09:05:50AM +0100, Kamil Dudka wrote:
On Thursday, February 24, 2022 3:37:56 PM CET Neal Gompa wrote:
On Thu, Feb 24, 2022 at 8:58 AM Richard W.M. Jones rjones@redhat.com
wrote:
On Thu, Feb 24, 2022 at 02:28:08PM +0100, Kamil Dudka wrote:
On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote:
Did you discuss modularising curl itself upstream?
It was added to their wish list but I do not remember anybody working on
it:
https://github.com/curl/curl/commit/8204844f
That would be a better idea.
Not necessarily. Each approach has its pros and cons.
I'm intrigued by what you think the cons would be. AFAICT if curl was modular in this way already we wouldn't be discussing this proposal at all, but a different and better one around packaging splits.
It would also avoid the usability nightmare that comes with trying to trigger switching implementations. This is a very big hammer that basically tells people that we're crippling curl by default for users and it has very large network effects across the entire distribution. It's quite one thing to use curl-minimal for containers where people expect tools to be broken in the endless pursuit of smaller base images, but when real people need to use real systems in complex configurations, having a reduced functionality curl by default is just going to lead to support nightmares and complaints about random breakages in applications on Fedora.
Installations that need libcurl-full will have it installed. There is no problem there. You could hardly find a default that will fit everybody's taste.
This seems to be an argument for always installing full curl.
BTW there *is* a worthwhile security enhancement that we should make to packages that use curl. We should audit programs to ensure they always call CURLOPT_PROTOCOLS[1] to specify exactly the protocols they expect. This avoids certain attacks where an evil webserver redirects to a less tested / exploitable protocol, and exploits the client through this. We had a qemu CVE related to this (CVE-2013-0249).
Rich.
[1] https://curl.se/libcurl/c/CURLOPT_PROTOCOLS.html