Re: [PATCH] Implement https public key pinning

[Jeff King <peff@peff.net>]

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