Re: [PATCH v4] http: add http.sslVerifyStatus to check stapled OCSP responses

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 18, 2026, 16:40 UTC
Message-ID: <xmqqecfv1iw8.fsf@gitster.g>
In-Reply-To: <aoQOxISPfEwh-ik2@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 6 quoted lines

> This is only part of the story though: GnuTLS 3.8 introduced
> GNUTLS_NO_STATUS_REQUEST, and curl 8.10 started to set that option in
> case of `!verifystatus`. So with new-enough versions of both libraries,
> Git behaves the same no matter whether we use OpenSSL or GnuTLS as
> backend. See also aeb1a281ca (gtls: fix OCSP stapling management,
> 2024-08-20) in curl.

Thanks for additional details.

Show 26 quoted lines

>> Add an http.sslVerifyStatus boolean that sets CURLOPT_SSL_VERIFYSTATUS.
>> Because http_options() is the collect_fn of a urlmatch config, the
>> per-URL form works with no further changes:
>> 
>>     git config http.https://example.com/.sslVerifyStatus true
>> 
>> It defaults to false, and has to. The option is fail-closed: libcurl fails
>> verification when the server staples nothing at all, so turning this on
>> globally would break every remote that does not staple.
>> 
>> Leaving the default to libcurl is not an option either. The same
>> complaint was raised there in https://github.com/curl/curl/issues/15483
>> and closed as intentional ("Marked as enhancement since this was done on
>> purpose"), with the observation that stapling is expected to see less use
>> as Let's Encrypt drops OCSP support. If the check is to be reachable at
>> all, the lever has to come from the application.
>
> But... don't we still leave the default to libcurl? If
> "http.sslVerifyStatus" is not set then we don't touch
> `CURLOPT_SSL_VERIFYSTATUS`, either.
>
> I might be misreading this though, as the whole commit message is quite
> hard to digest. I'd assume that this is because it's generated by AI,
> and it added a lot of the usual weird phrases to the message. It might
> be a good idea to adapt the message to have a bit more of a human touch
> to it.

I too had trouble figuring out what the proposed log message really wanted to say, but I wrote it off, blaming the difficulty on a language barrier. But as you said, perhaps it is because it was written by something that does not truly understand what it is talking about. It may not have to explain things to readers as if they were 5 years old, but it is definitely necessary to explain well to readers as if they were humans with average intelligence ;-).