Wei Shuyu wrote:
> Git has been taught to support an https:// used for http.proxy when
> using recent versions of libcurl.
nit: commit messages use the imperative mood, as though commanding the
code base to do something:
Support https:// for http.proxy when using recent versions of
curl.
[...]
> To use https proxy with self-signed certs, we need a way to
> unset CURLOPT_PROXY_SSL_VERIFYPEER and CURLOPT_PROXY_SSL_VERIFYHOST
> just like direct SSL connection. This is required if we want
> use t/lib-httpd to test proxy.
Interesting. Sounds promising.
> In this patch I reuse http.sslverify to do this, do we need an
> independent option like http.sslproxyverify?
I think a separate option is a good idea. This way, I can use
[http "https://example.com";]
sslVerify = false
to fetch from a misconfigured server or
[http "https://example.com";]
proxy = https://127.0.0.1
sslVerifyProxy = false
to proxy through a misconfigured proxy. Alternatively, is there a
straightforward way to make
[http "https://example.com";]
proxy = https://127.0.0.1
[http "https://127.0.0.1";]
sslVerify = false
do that? Something like
struct urlmatch_config proxy_config = { STRING_LIST_INIT_DUP };
config.section = "http";
config.key = NULL;
config.collect_fn = proxy_options;
config.cascade_fn = git_default_config;
config.cb = NULL;
config.url = normalized_proxy_url;
git_config(urlmatch_config_entry, &config);
How does this interact with the GIT_SSL_NO_VERIFY environment
variable?
> To fully support https proxy, we also need ways to set more options
> such as CURLOPT_PROXY_SSLCERT. However, I'm not sure if we need to
> support them.
That's for client certs, right? Would it work to make that
configurable as
[http "https://127.0.0.1";]
sslCert = ...
?
That said, I agree with you that it's not a prerequisite for this
initial patch.
Thanks,
Jonathan
