On Wed, Mar 29, 2023 at 11:53:11AM -0700, Junio C Hamano wrote:

quoted

In my opinion they need the same set of tests which is used as usual
for https. But use the right certificate and key.
But I don't have any idea how to do that with hardware usb eToken in my case.

OK, so where does this put us, with respect to the change?  We have
some behaviour change that we do not know how to test?  How would we
know when we break it in the future?  It is not like the new feature
is not useful enough that nobody would care if it gets broken by
accident or anything like that, so...?

At least perhaps we can throw bogus strings in the environment and
make sure cURL library gives complaints, or something?

I would be OK taking the patches without any further tests. It is not
really making anything worse in the sense that we already do not test
any of the client-cert stuff.

If we can cheaply add some tests that at least exercise the code and
hand off to curl, that is better than nothing, I guess.

I think the ideal would be a new t5565 that sets LIB_HTTPD_SSL
unconditionally and actually tests various client-cert formats and
requests using a made-on-the-fly cert. But I don't want to hold up a
patch we otherwise think is OK on the basis of long-term technical debt
we already have.

-Peff