From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: graysongordon-gl <graysongordon1@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v4] http: add http.sslVerifyStatus to check stapled OCSP responses
Date: Tue, 18 Aug 2026 09:40:55 -0700 [thread overview]
Message-ID: <xmqqecfv1iw8.fsf@gitster.g> (raw)
In-Reply-To: <aoQOxISPfEwh-ik2@pks.im> (Patrick Steinhardt's message of "Tue, 18 Aug 2026 09:50:28 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> 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.
>> 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
;-).
next prev parent reply other threads:[~2026-08-18 16:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 17:02 [PATCH] http: add http.sslVerifyStatus to check stapled OCSP responses graysongordon-gl
2026-08-11 19:28 ` Junio C Hamano
2026-08-11 20:44 ` [PATCH v2] " graysongordon-gl
2026-08-12 6:25 ` Patrick Steinhardt
2026-08-12 15:53 ` Grayson Gordon
2026-08-12 14:17 ` Junio C Hamano
2026-08-12 18:25 ` [PATCH v3] " graysongordon-gl
2026-08-12 21:34 ` Junio C Hamano
2026-08-13 16:06 ` Junio C Hamano
2026-08-17 18:52 ` [PATCH v4] " graysongordon-gl
2026-08-17 19:19 ` Junio C Hamano
2026-08-18 7:50 ` Patrick Steinhardt
2026-08-18 14:51 ` Grayson Gordon
2026-08-18 16:40 ` Junio C Hamano [this message]
2026-08-18 19:37 ` [PATCH v5] " graysongordon-gl
2026-08-18 20:12 ` Junio C Hamano
2026-08-18 21:22 ` Grayson Gordon
2026-08-18 21:48 ` [PATCH v6] " graysongordon-gl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqecfv1iw8.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=graysongordon1@gmail.com \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.