On 05/04/2012 09:16 AM, Jeff King wrote: > On Thu, May 03, 2012 at 06:39:54PM +0200, Nelson Benitez Leon wrote: > >> If http_proactive_auth flag is set and there is a username >> but no password in the proxy url, then interactively ask for >> the password. >> >> This makes possible to not have the password written down in >> http_proxy env var or in http.proxy config option. >> >> Also take care that CURLOPT_PROXY don't include username or >> password, as we now set them in the new set_proxy_auth() function >> where we use their specific cURL options. > > Do we actually need to do that? If we set CURLOPT_PROXYUSERNAME, will > curl ignore it in favor of what's in the URL? I explicitly remove username/pass from CURLOPT_PROXY to not having to worry about that question, to not provide cURL with two different sets of proxy auth info, common sense dictates cURL specific proxy options should take precedence over embedded in url by I haven't seen that mentioned by any cURL docs so we should look at the source to know the truth but even then that could change in the future so I think is safer to only provide one path for auth info. Having username/password on the CURLOPT_PROXY option gives us no special gain at the cost of not permitting usernames with reserved characters like '@' or ':' which are not unusual at all. So I'm inclined to preserve current set_proxy_auth() function and re-introduce the code that sets CURLOPT_PROXY with only $prot://$host. Are you ok with this? or do you prefer I change set_proxy_auth() to a set_curl_proxy() function where I embedded user/pass in CURLOPT_PROXY ? that is the remaining thing I need to know to send a new re-roll. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html