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

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 <[email protected]> wrote:
>
> graysongordon-gl <[email protected]> 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.