Re: [PATCH v2] http: add support for different sslcert and sslkey types.
- From
Jeff King <peff@peff.net>
- Date
- Mar 29, 2023, 23:23 UTC
- Message-ID
- <20230329232347.GB2314218@coredump.intra.peff.net>
- In-Reply-To
- <xmqqfs9n9yp4.fsf@gitster.g>
On Wed, Mar 29, 2023 at 11:53:11AM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> > 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