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

["SZEDER Gábor" <szeder.dev@gmail.com>]

On Wed, Sep 23, 2026 at 02:47:18PM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder.dev@gmail.com> writes:
> 
> > On Tue, Sep 15, 2026 at 12:23:48PM -0400, graysongordon-gl wrote:
> >> From: Grayson Gordon <graysongordon1@gmail.com>
> >> 
> >> 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.
> > ...
> > This patch was merged to 'next' the other day, and the last test in
> > the new t5585 fails on my system.
> 
> Sorry about a premature merge.  Since we are not in a hurry to take
> this topic in (or no new feature topic in general), let me revert it
> out of 'next' and give it a clean slate to try again.

Well, if you hadn't merged it, we would perhaps still be none the
wiser, because, alas, I don't have the bandwidth to run tests on the
seen branch regularly...

However, CI does, but I can't seem to find any CI runs that failed
because of this, which makes me worried that something is wrong on my
end.

> > ...
> > I added that 'cat err' to see the error message.  Turns out that 'git
> > ls-remote' can't even find the repository on the remote, but the
> > prereq is still considered fulfilled.  Is that right?
> > ...
> > This time the error message talks about missing OCSP response, but the
> > prereq is still considered fulfilled.  Again: is that right?!
> >
> > Instead of the lack of a certain string in the error message, is
> > there something positive that we can test instead?
> 
> Oh, that is a very constructive and useful suggestion.  Greatly
> appreciated.

After having slept on it :) I now start to realize that this
SSL_VERIFYSTATUS prereq only checks that libcurl supports the
CURLOPT_SSL_VERIFYSTATUS option, and has nothing to do with the
capabilities and configuration of the web server.  If my understanding
is correct, then I think that:

  - Merely attempting a connection to somewhere is indeed sufficient
    to check this, and it doesn't matter that the server can't find
    the requested repository.  

  - Checking for the error message printed after curl_easy_setopt(...,
    CURLOPT_SSL_VERIFYSTATUS, ...) returns with error is indeed the
    right thing to do.

    However, in that new error message the second half is much more
    informative than the first, and if the prereq looked for the
    absence of "could not enable OCSP status verification" instead of
    "http.sslVerifyStatus is set", then I think I would have realized
    all this sooner.  Perhaps calling the prereq CURL_SSL_VERIFYSTATUS
    would have helped, too.