Yes. If you set bogus strings  in the environment cURL should return
an error the same as if you set the wrong file for certificate or key.

So you can set

GIT_SSL_CERT=some_real_pem_file  - That should work (PEM type used by default)

GIT_SSL_CERT=some_real_pem_file  GIT_SSL_CERT_TYPE=PEM - That should work too

GIT_SSL_CERT=some_real_pem_file  GIT_SSL_CERT_TYPE=Bogus - That shouldn't work

GIT_SSL_CERT=some_real_der_file  GIT_SSL_CERT_TYPE=DER - I am not sure
about that, because as I far remember there issue with DER in openssl

I think that more detailed information there:
https://curl.se/libcurl/c/CURLOPT_SSLKEYTYPE.html

Basically that only a format of cert and key file or engine in case of
pkcs11 url instead of file in others cases.

So if you set it into right values, respect your ssl cert and ssl key
- https should work. But if not, error from curl should returned

ср, 29 мар. 2023 г. в 21:53, Junio C Hamano [off-list ref]:

Stanislav M [off-list ref] writes:

[administrivia: do not top-post]

quoted

quoted

Yes, but I'm not sure if there is a way for Git to trigger curl to look
at the certificate that does not involve feeding it an https URL (and we
want a valid one, because we want to see that it correctly speaks to the
server).

...
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?

Thanks.