quoted

@@ -1014,10 +1020,14 @@ static CURL *get_curl_handle(void)

      if (ssl_cert)
              curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
+     if (ssl_cert_type)
+             curl_easy_setopt(result, CURLOPT_SSLCERTTYPE, ssl_cert_type);

We're just feeding curl whatever string the user gave us (which is good,
since we don't know which ones are valid). But what happens with:

  GIT_SSL_CERT_TYPE=bogus git fetch ...

Should we check for an error here, or will the actual request later
complain properly?

Curl itself validates that string. And if we pass the wrong type or
not pass 'ENG' in case of pkcs11: curl will return an error. In that
case git do the same if GIT_SSL_CERT passed wrong ss 'ENG' in case of
pkcs11: curl will return an error. In that case git do the same if
GIT_SSL_CERT passed wrong


пн, 20 мар. 2023 г. в 20:10, Jeff King [off-list ref]:

On Mon, Mar 20, 2023 at 03:48:49PM +0000, Stanislav Malishevskiy via GitGitGadget wrote:

quoted

From: Stanislav Malishevskiy <redacted>

Basically git work with default curl ssl type - PEM. But for support
eTokens like SafeNet tokens via pksc11 need setup 'ENG' as sslcert type
and as sslkey type. So there added additional options for http to make
that possible.

Seems like a reasonable thing to want, and the patch looks pretty clean.
Two small points:

quoted

 http.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

There are no tests here. I think it might be possible to add them, but
our https test support is currently optional, and has bit-rotted a bit
over the years. There's some discussion here:

  https://lore.kernel.org/git/Y9s7vyHKXP+TQPRm@pobox.com/ (local)

So I don't think it makes sense to block this patch over the lack of
tests, but it's something we might keep in mind to add if the test
situation improves.

quoted

@@ -1014,10 +1020,14 @@ static CURL *get_curl_handle(void)

      if (ssl_cert)
              curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
+     if (ssl_cert_type)
+             curl_easy_setopt(result, CURLOPT_SSLCERTTYPE, ssl_cert_type);

We're just feeding curl whatever string the user gave us (which is good,
since we don't know which ones are valid). But what happens with:

  GIT_SSL_CERT_TYPE=bogus git fetch ...

Should we check for an error here, or will the actual request later
complain properly?

-Peff