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
