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 [off-list ref] wrote:

graysongordon-gl [off-list ref] writes:

quoted

+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.