On 1/10/2019 5:25 PM, Daniel Stenberg via curl-library wrote:
> I want to test an idea on you all before I proceed and do anything
> else with it. I need your input, your critique and perhaps your
> suggestions on how to make into an awesome idea.
>
> The problem
>
>  You - as a user - run programs and scripts that themselves use
> libcurl or
>  just the command line curl, in ways that you don't approve of. Even
> if the
>  program or script was written to do use that feature.
>
> The solution
>
>  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.
>
>  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.
>
>  Restrictions should be named to identify what is *inhibited* by it.
>
>  The general idea here is that applications and scripts using curl can't
>  change or work around restrictions set in this variable!
>
>   Restrictions
>
>  Here are three that I immediately came to think of. I'd be interested in
>  adding others to the list if you can think of some!
>
>  'clear-text'
>
>  When set, this will make libcurl avoid downloads over clear-text
> connections.
>  The transfer MUST be encrypted or trigger an error (`CURLE_INIHIBITED`).
>
>  'user-in-url'
>
>  When set, this is the equivalent of the application setting the
>  `CURLOPT_DISALLOW_USERNAME_IN_URL` option. It will prevent libcurl from
>  accepting URLs with embedded user names.
>
>  'insecure-https'
>
>  When set, this will make transfers that are attempted with server
> certificate
>  validation disabled to fail.
>
> Anything you think you would ever use and appreciate?
>

I really don't like it. I didn't think I'd be the contrarian on this
one. I'm against anything that can break scripts/programs. Devs want to
know when they use curl/libcurl it's going to do what they tell it to
do. We are already breaking that a little by having SSL backend-specific
option values like to specify ciphers etc, or more broad like http well
we assume most libcurl will be built with http and it seems to me
invariably it is. For the most part I think the developer should not
have to worry about problems like that. curl should do what they tell it
to do they shouldn't have to guess on external factors. Make this
transfer, goodbye. I see a world where everyone starts peppering their
scripts to nullify CURL_INHIBIT.

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