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
