On Wed, Dec 14, 2016 at 04:29:52PM -0600, Blake Burkhart wrote: > You may want to set CURLOPT_DEFAULT_PROTOCOL if we don't already. Apparently > the default value of NULL causes it to make a guess based on the host if no > protocol is present. But you are discussing a situation where "http://"; is > present, so that doesn't apply. Cute. I agree it doesn't matter here, where we're sure there's a protocol specifier at the beginning. It might matter if you instruct git to use a specific remote-helper, like: $ echo 127.0.0.1 ftp.example.com >>/etc/hosts $ git clone http::ftp.example.com which will try to connect via ftp. Of course that's no different than: $ git clone http::ftp://example.com which you can already do. git-clone sees "http::" and hands it off to git-remote-http, which then processes the rest of the arguments as it sees fit (in this case, handing it off to curl). Prior to these more recent patches I suspect you could do: $ git clone http::file://whatever but now we set CURLOPT_PROTOCOL to restrict it to just http/ftp (so you can be confusing by asking for http and ending up in curl to do ftp, but in any such case you could also have just asked for ftp in the first place). > Also, I thought we left out ftp because it was deprecated, but I don't > remember exactly. I couldn't find anything interesting in the archives (neither the public list nor git-security). Given how unlikely it is to be used, it does seem like a good idea to keep it in the "maybe" category, if only because it decreases the attack surface (and for those following along, we're just talking about not-from-user uses here, so people sticking a funny ftp URL in .gitmodules, or redirecting http to ftp, etc). -Peff