On Wed, 10 Mar 2010, Yang Tse wrote:

> I'm not sure everyone using an OpenSSL enabled libcurl, either static or
> dynamic version, would want to allow any user, or script, capable of setting
> OPENSSL_CONF environment variable to modify application behavior beyond
> developers or distributors control.

I agree with that in general, but in this particular case: what's the worst
bad thing a user could do if it was given this ability without the app's
consent?

> In any case, we could allow any application using libcurl to specify if they
> chose to ignore or honor OPENSSL_CONF environment variable introducing a new
> flag for curl_global_init(). For example CURL_GLOBAL_SSL_CONF or the
> contrary CURL_GLOBAL_SSL_NOCONF. If we continue with the no-surprises
> policy, the default should probably be to not honor the OPENSSL_CONF
> environment variable unless curl_global_init() is called with flag
> CURL_GLOBAL_SSL_CONF set.

Yes, this makes sense.

> On the other hand it could be interesting to enable the feature as default
> for curl tool.

Right, but we can just modify curl to allow the use of that variable if we end
up going this route.

> Additionally, when OPENSSL_CONF is used it could be interesting to attempt
> to get configuration values from a [libcurl_conf] specific section in order
> to allow greater flexibility.

That's not a bad idea. I'm not really familiar with this config file or in
what exact circimstances it is used to fully qualify the merits of this
suggestion though.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html