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 <gitster@xxxxxxxxx>: > > Stanislav M <stanislav.malishevskiy@xxxxxxxxx> writes: > > [administrivia: do not top-post] > > >> 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.
