Re: [PATCH] docs: indicate http.sslCertType and sslKeyType
- From
Andrew Carter <andrew@emailcarter.com>
- Date
- Jan 25, 2025, 06:38 UTC
- Message-ID
- <f89f8ed0-1d0c-41f4-9360-4fd01b52a517@emailcarter.com>
- In-Reply-To
- <xmqq7c6ltoib.fsf@gitster.g>
On 1/23/25 11:43 AM, Junio C Hamano wrote:
Show 55 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> writes: > >> On 2025-01-23 at 00:16:06, Andrew Carter via GitGitGadget wrote: >>> diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt >>> index a14371b5c96..cd39e182527 100644 >>> --- a/Documentation/config/http.txt >>> +++ b/Documentation/config/http.txt >>> @@ -216,6 +216,18 @@ http.sslBackend:: >>> This option is ignored if cURL lacks support for choosing the SSL >>> backend at runtime. >>> >>> +http.sslCertType:: >>> + Type of client certificate used when fetching or pushing over HTTPS. >>> + (e.g. "PEM", "DER", or "P12"). See also libcurl `CURLOPT_SSLCERTTYPE` >>> + Can be overridden by the `GIT_SSL_CERT_TYPE` environment variable. >>> + >>> +http.sslKeyType:: >>> + Type of client private key used when fetching or pushing over HTTPS. >>> + (e.g. "PEM", "DER", or "ENG"). Particularly useful when set to "ENG" >>> + for authenticating with PKCS#11 tokens. See also libcurl >>> + `CURLOPT_SSLCERTTYPE` . Can be overridden by the `GIT_SSL_KEY_TYPE` >>> + environment variable. >> Are there any particular limitations on these values that are platform- >> or backend-specific that we should document? For instance, I seem to >> recall that at some point PKCS#12 files were limited to schannel or >> Windows, although I could be mistaken. >> >> Do we also have documentation for whatever engine parameter is required >> according to the libcurl documentation? > Both are very good points. > > I went back to the original thread that added the change cited in > the proposed log message [*1*], hoping that maybe somebody brought > up caveats but didn't find anything relevant other than that we > punted to add tests for this since it was too cumbersome to set up. > > Note to Andrew, when referring to an existing commit in your > proposed log message, please do not just write its abbreviated > commit object name, like 0a01d41e. > > Instead, use it in "git show -s --format=reference 0a01d41e" to > obtain something like > > 0a01d41ee4 (http: add support for different sslcert and sslkey > types., 2023-03-20) > > that would help people to immediately see what the change was about > and how old it was. > > Thanks. > > > [Reference] > > *1* https://lore.kernel.org/git/pull.1474.v2.git.git.1679327330032.gitgitgadget@gmail.com/
Thanks for the rapid feedback!
I was leaning away from including too many libcurl-specific details in my original patch, but I see I went too far, and these options are misleading or at least hard to decipher from my initial patch.
As you mentioned, per the curl documentation [1] the supported values are fairly backend-specific.
Git doesn't currently expose the openssl "engine" option. Because the default engine in openssl is "dynamic", in my use case, just setting the SSLKEYTYPE to "ENG" and using a PKCS#11 url in the sslKey field works. I can make a patch to introduce the option if that's desired.
I have something written up that includes backend caveats, and I will submit another patch this weekend.
Thanks for the correction on the commit reference. Please correct/forgive any list etiquette mistakes.
-AC
1. https://curl.se/libcurl/c/CURLOPT_SSLKEYTYPE.html https://curl.se/libcurl/c/CURLOPT_SSLCERTTYPE.html