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

[Patrick Steinhardt <ps@pks.im>]

On Fri, Aug 28, 2026 at 10:20:31AM -0700, Junio C Hamano wrote:
> Grayson Gordon <graysongordon1@gmail.com> writes:
> 
> > Junio,
> >
> > Yes, I was hoping for clarity on how thorough we wanted the testing to
> > be. Patrick added a lot of great stuff that I’m happy to use if that’s
> > your preference, but we also talked about wanting to keep the tests
> > succinct. Please let me know what you feel is most appropriate.
> 
> If you can keep them succinct but still test the essential bits,
> that would be great, but I am not sure if that is a great question
> to ask me ;-)  Patrick?  You said "not 100% sure given the complexity",
> but which parts make you feel iffy? 

Setting up OCSP is quite a pain, and that is what made me feel iffy.
That being said, given that this is a security-focussed feature I feel
like we should probably bite the bullet and verify that we indeed know
to reject servers that respond with invalid stapled responses.

And given that this whole setup is now getting more complex I feel like
it's worth it to also allocate a new test number for it.

> They do look involved but seem to cover the situations we do care
> about, except we seem not to test when the server does not explicitly
> say "this is still good", or am I not reading the tests correctly?

Isn't the following test covering that scenario? Or am I misreading?

    test_expect_success SSL_VERIFYSTATUS 'fetch succeeds with stapled "good" OCSP response'
           with_ssl_verification git -c http.sslVerifyStatus=true \
                   ls-remote "$HTTPD_URL/smart/repo.git" >actual &&
           test_line_count -gt 0 actual
    '

Thanks!

Patrick