On Wed, Mar 29, 2023 at 11:53:11AM -0700, Junio C Hamano wrote: > > 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
