Re: [PATCH v6] http: add http.sslVerifyStatus to check stapled OCSP responses
From: Junio C Hamano <hidden>
Date: 2026-08-26 22:01:52
graysongordon-gl [off-list ref] writes:
From: Grayson Gordon <redacted>
git never sets CURLOPT_SSL_VERIFYSTATUS, so libcurl never requests the
OCSP "Certificate Status Request" extension and any stapled response a
server sends is ignored, including responses that explicitly state the
certificate has been revoked.
Add an http.sslVerifyStatus boolean that maps to
CURLOPT_SSL_VERIFYSTATUS.
http_options() is already the collect_fn for a urlmatch config, so the
per-URL form works with no changes:
git config http.https://example.com/.sslVerifyStatus true
Defaults to false/"off". This is due to the nature of the OCSP protocol.
If enabled, git would expect to receive OCSP stapled responses. If the
stapled responses were not present, the connection would be blocked as
the status of the server's certificate could not be verified. This would
break connections to legitimate services that don't use OCSP as their
certificate revocation mechanism.
If the backend can't check the staple, curl_easy_setopt() returns
CURLE_NOT_BUILT_IN. Error message includes curl_easy_strerror() with
the option name to enable users to more easily identify a libcurl
built without status verification.
CURLOPT_SSL_VERIFYSTATUS has existed since libcurl 7.41.0, below our
7.61.0 floor, so no version guard is needed.
Tests are in t5551.
Additional note - I put this in http.adoc:
"Defaults to false, which
allows connections to remotes without validating whether or not
the certificate has been revoked by the certificate authority."
Technically, there are cases with older combinations of GnuTLS
and curl where the revocation logic actually WILL NOT allow
such connections. Search "OCSP" in the lore for full details.
Signed-off-by: Grayson Gordon <redacted>
---
Documentation/config/http.adoc | 14 ++++++++++++++
http.c | 14 ++++++++++++++
t/t5551-http-fetch-smart.sh | 29 +++++++++++++++++++++++++++++
3 files changed, 57 insertions(+)Are folks happy with this iteration? I think we have already reached the point of diminishing returns before the thread went dark. Thanks.