Hi,

My initial impression is that this helps address a real problem, but the
use cases need to be considered.

An all cases, you want to avoid the pattern becoming:
  CURL_INHIBITED=; curl http://etc ...
Likewise, you don't want to make this become the pattern either:
  wget http://etc/...; ...

For the use case where the user is unaware that a script will use curl to
insecurely download executable content the documentation should strongly
encourage using read only variables, for example in bash:
  declare -r CURL_INHIBITED=value

For the enterprise use case where a corporate user wants to do something
unadvisable and is both persistent and unaware of the risks a custom
message would be useful:
  declare -r CURL_INHIBITED=value
  declare -r CURL_INHIBITED_MSG="See https://short/client_security#curl"

Consider that this is a policy setting that can apply to curl, wget and
other programs. Did you want to use a more generic name for the variables
to encourage other programs to adopt them, or did you want to start with a
small scope to simplify the initial implementation?

On Fri, Jan 11, 2019 at 9:28 AM Daniel Stenberg via curl-library <
curl-library_at_cool.haxx.se> wrote:

> Hey,
>
> 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?
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html

-- 
Sean Burford |  Make Tracks by Area 120 |  sburford_at_google.com |  +1
650-253-1481

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