On Fri, Feb 12, 2016 at 11:02:26AM +0100, Thomas Gummerer wrote: > > Also some people suggested that git should fail if this option is > > requested in the config but not supported by the libcurl version instead > > of falling back to just not pin the key. I'm undecided about that. > > This seems to have been suggested off list (or at least I can't find > the message). FWIW I do agree with failing or as a bare minimum > warning the user if the config option is set, but not supported by the > libcurl version. Otherwise we risk giving the user a false sense of > security when the option is set, which is arguably worse than not > having the security option at all. We can't do this perfectly, because older versions of git do not yet know about the option, and will therefore just silently ignore it. And for consistency there, we usually do the same for features that we know about but are unsupported. But I agree for something with security implications like this, we are better off warning when we know support is not built in. That's not perfect, but it's better than nothing. I wonder if there are other options which should get the same treatment. Most of the obvious ones I could think of (e.g., http.sslverify) do not need it, because either they always have support built, or they fail-closed, or both. -Peff -- 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