From: SZEDER Gábor Date: Thu, 24 Sep 2026 07:41:41 GMT Subject: Re: [PATCH v7] http: add http.sslVerifyStatus to check stapled OCSP responses Message-ID: In-Reply-To: On Wed, Sep 23, 2026 at 02:47:18PM -0700, Junio C Hamano wrote: > SZEDER Gábor writes: > > > On Tue, Sep 15, 2026 at 12:23:48PM -0400, graysongordon-gl wrote: > >> From: Grayson Gordon > >> > >> 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.