Re: [PATCH v7] http: add http.sslVerifyStatus to check stapled OCSP responses
- From
SZEDER Gábor <szeder.dev@gmail.com>
- Date
- Sep 24, 2026, 07:41 UTC
- Message-ID
- <arTUNYVvCNwX1pDp@szeder.dev>
- In-Reply-To
- <xmqqwlsb63o9.fsf@gitster.g>
On Wed, Sep 23, 2026 at 02:47:18PM -0700, Junio C Hamano wrote:
Show 16 quoted lines
> 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.
Show 13 quoted lines
> > ... > > 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.