Re: [PATCH v5] http: add http.sslVerifyStatus to check stapled OCSP responses
- From
- Grayson Gordon <graysongordon1@gmail.com>
- Date
- Aug 18, 2026, 21:22 UTC
- Message-ID
- <CALgUfNg1yryPygp_UVp9cGFfiUe7_6Uqx3ExBt=10Qh+PKG2QQ@mail.gmail.com>
- In-Reply-To
- <xmqqo6ezw5l1.fsf@gitster.g>
Junio,
By "fail-closed" I was specifically referring to the case where no OCSP stapled response was provided. Failing open in this context would mean that, despite verifystatus being set, a response with no stapled response is ALLOWED.
Maybe I'm just a very irregular human being lol.
I'll update the adoc to be similar to what you provided. I refer to the edge cases/different behaviors that we talked about earlier in this thread with the older curl and gnutls versions in the commit message and keep the adoc as simple as possible.
- Grayson
On Tue, Aug 18, 2026 at 4:12 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 27 quoted lines
>
> graysongordon-gl <graysongordon1@gmail.com> writes:
>
> > +http.sslVerifyStatus::
> > + Whether to check the revocation status of the server
> > + certificate using the stapled OCSP response supplied during
> > + the TLS handshake ("OCSP stapling"). Defaults to false.
> > ++
> > +This is fail-closed: if the server staples no response, verification
> > +fails. Set it per remote, e.g.
> > +`http.https://example.com/.sslVerifyStatus`, rather than globally.
>
> I do not see us describe a knob or setting that can stop the
> operation depending on some condition as "fail-closed". Can we
> rephrase this for regular human beings? Perhaps
>
> Whether to refuse connecting to the server when its
> certificate has been revoked. Default to false, allowing
> connection even when its certificate is not known to be
> still valid.
>
> or something like that might be a good starting point. After all,
> the "check revocation and/or validity" is *not* the primary
> objective from the end-user's point of view. Ensuring that they do
> not talk to suspicious servers is.
>
> Thanks.