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
