On Fri, Aug 11, 2017 at 05:30:34PM -0700, Junio C Hamano wrote: > > -#if LIBCURL_VERSION_NUM >= 0x071304 > > +#ifdef CURLPROTO_HTTP > > curl_easy_setopt(result, CURLOPT_REDIR_PROTOCOLS, > > get_curl_allowed_protocols(0)); > > curl_easy_setopt(result, CURLOPT_PROTOCOLS, > > This may make the code to _compile_, but is it sensible to let the > code build and be used by the end users without the "these protocols > are safe" filter, I wonder? > > Granted, ancient code was unsafe and people were happily using it, > but now we know better, and more importantly, we have since added > users of transport (e.g. blindly fetch submodules recursively) that > may _rely_ on this layer of the code safely filtering unsafe > protocols, so... I don't think Tom's patch changes this in any meaningful way. The "fallback to skipping the safety and showing a warning" dates back to the original introduction of the feature. But FWIW, that is exactly the kind of thing that led me to wanting to implement a hard cutoff in the first place. The warning is small consolation if Git allows an attack through anyway. Or worse, you don't even see the warning because it's an automated process that is being exploited. There's a good chance if you have such an antique curl that it is also riddled with other curl-specific bugs that have since been fixed. And that would argue that we don't need to care that much anyway; people running old curl have decided that it's not worth caring about the security implications. But in the case of RHEL, in theory they are patching security bugs in curl but just not implementing new features. So if we have a vulnerability introduced by using an old version of curl, we really are making things worse. And that argues for having a hard cutoff. But as Tom's series demonstrates, they are backporting _some_ features (presumably ones needed by other programs like Git to fix security bugs). Which argues for having #ifdefs that handle those backports, which in theory gives us a secure Git on systems that do careful backporting, and gives us an insecure-but-not-worse-than-it-already-was Git on systems that don't do backporting. I dunno. There were a lot of assumptions and mental gymnastics there. I'm still tempted to target curl >= 7.19.4 just based on timing and RHEL5's support life-cycle. -Peff