On Thu, Jan 10, 2019 at 11:25:14PM +0100, Daniel Stenberg via curl-library wrote:
> The all new `CURL_INHIBIT` environment variable, that is parsed by libcurl
> and can be used to make libcurl avoid certain behaviors.
>
> Using this, you can voluntary raise the bar for what's accepted, to prevent
> scripts and programs from for example using insecure protocols etc.

This sounds promising. Of course, applications ought to be providing knobs for
users to tweak these kinds of settings already, so I'm assuming this proposal
is aimed at applications that *don't* already provide such knobs.

> The variable should contain a comma-separated list of named restrictions. The
> restrictions available are listed below, but other ones may be added in later
> libcurl versions (and older may be removed). Unknown or just misspelled
> restrictions will be silently ignored.

The examples look like they roughly correspond to curl_easy_setopt options
already, which begs the question: why stop at just these? There are times
times when I'd like to enable arbitrary options in an existing application to
work around issues. Why not provide access to most of the setopt options (that
make sense to be controlled by the user)?

I'm bringing this up mostly as a straw man to try to nail down just what this
proposal is intended to accomplish. I can think of lots of options that could
be useful to add to this list that fit right along with it (e.g., disabling
TLS1.0, NTLMv1, MD5 digest auth, MD5-signed certificates, disabling arbitrary
encryption protocols, disabling arbitrary transfer protocols, adding an SSH hostkey
check when there isn't one already). But I can also think of lots of others
that don't really enhance security but might be handy to be able to override at
run time anyway if the application doesn't already provide a way (e.g., connect
timeouts, user agent override, disabling TLS hostname check, enabling SSH
compression, adding an ftp prequote command, adding an arbitrary HTTP header,
turning on HTTP redirect following, adding the CURLOPT_FTP_ALTERNATIVE_TO_USER
option). Once this mechanism is in place, people will probably start asking for
all kinds of these sorts of overrides. Is that something you'd be prepared to
argue against? If not, then is it something you'd allow, and for either answer,
why?

>>> Dan
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-01-11