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@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 | sburf...@google.com | +1 650-253-1481
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
