document http.sslCertType and sslKeyType #1854
Conversation
Welcome to GitGitGadgetHi @plentydone, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that either:
You can CC potential reviewers by adding a footer to the PR description with the following syntax: NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description, Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description): To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join [email protected], where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join. You may also be able to find help in real time in the developer IRC channel, |
|
There are issues in commit 90a7e1a: |
plentydone
force-pushed
the
curl-cert-options
branch
from
90a7e1a to
506fcdc
Compare
|
There are issues in commit 506fcdc: |
plentydone
force-pushed
the
curl-cert-options
branch
from
506fcdc to
5e27541
Compare
|
@dscho at your convenience I would appreciate a |
plentydone
force-pushed
the
curl-cert-options
branch
from
5e27541 to
efff4a8
Compare
|
@hickford if you could throw a |
|
/allow |
|
User plentydone is now allowed to use GitGitGadget. WARNING: plentydone has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use. |
|
/preview |
|
Preview email sent as [email protected] |
These useful config options were added in 0a01d41 but lacked documentation. Signed-off-by: Andrew Carter <[email protected]>
plentydone
force-pushed
the
curl-cert-options
branch
from
413bb58 to
fde67ef
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, "brian m. carlson" wrote (reply to this): 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?
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA |
|
User |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): "brian m. carlson" <[email protected]> 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/[email protected]/ |
|
This patch series was integrated into seen via git@5a7449b. |
|
This branch is now known as |
|
This patch series was integrated into seen via git@844a219. |
|
There was a status update in the "New Topics" section about the branch Two configuration variables about SSL authentication material that weren't mentioned in the documentations are now mentioned. Waiting for review response. cf. <[email protected]> source: <[email protected]> |
|
On the Git mailing list, Andrew Carter wrote (reply to this): On 1/23/25 11:43 AM, Junio C Hamano wrote:
> "brian m. carlson" <[email protected]> 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/[email protected]/
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
|
|
This patch series was integrated into seen via git@a1b78c0. |
|
This patch series was integrated into seen via git@ec71372. |
|
This patch series was integrated into seen via git@2e85d7a. |
|
This patch series was integrated into seen via git@875c608. |
|
This patch series was integrated into seen via git@9909a52. |
|
There was a status update in the "Cooking" section about the branch Two configuration variables about SSL authentication material that weren't mentioned in the documentations are now mentioned. Waiting for review response. cf. <[email protected]> source: <[email protected]> |
|
This patch series was integrated into seen via git@dda70ab. |
|
On the Git mailing list, Andrew Carter wrote (reply to this): 0a01d41ee4 (http: add support for different sslcert and sslkey types.,
2023-03-20) added useful SSL config options, but did not document them.
Signed-off-by: Andrew Carter <[email protected]>
---
Documentation/config/http.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt
index a14371b5c9..38e874307b 100644
--- a/Documentation/config/http.txt
+++ b/Documentation/config/http.txt
@@ -216,6 +216,21 @@ 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.
+ "PEM", "DER" are supported when using openssl or gnutls backends. "P12"
+ is supported on "openssl", "schannel", "securetransport", and gnutls 8.11+.
+ 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"). Only applicable when using "openssl" backend. "DER"
+ is not supported with openssl. Particularly useful when set to "ENG" for
+ authenticating with PKCS#11 tokens, with a PKCS#11 URL in sslCert option.
+ See also libcurl `CURLOPT_SSLCERTTYPE`. Can be overridden by the
+ `GIT_SSL_KEY_TYPE` environment variable.
+
http.schannelCheckRevoke::
Used to enforce or disable certificate revocation checks in cURL
when http.sslBackend is set to "schannel". Defaults to `true` if
--
2.39.5 (Apple Git-154) |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): Andrew Carter <[email protected]> writes:
> 0a01d41ee4 (http: add support for different sslcert and sslkey types.,
> 2023-03-20) added useful SSL config options, but did not document them.
>
> Signed-off-by: Andrew Carter <[email protected]>
> ---
> Documentation/config/http.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
warning: Patch sent with format=flowed; space at the end of lines might be lost.
error: corrupt patch at line 10
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Applying: docs: indicate http.sslCertType and sslKeyType
Patch failed at 0001 docs: indicate http.sslCertType and sslKeyType
I thought that the initial iteration I received from you on Jan 23rd
was just fine. Did you change some settings with your MUA? The patch
is heavily whitespace damaged, with full of .
> diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt
> index a14371b5c9..38e874307b 100644
> --- a/Documentation/config/http.txt
> +++ b/Documentation/config/http.txt
> @@ -216,6 +216,21 @@ 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.
> + "PEM", "DER" are supported when using openssl or gnutls backends. "P12"
> + is supported on "openssl", "schannel", "securetransport", and
> gnutls 8.11+.
> + 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"). Only applicable when using "openssl"
> backend. "DER"
> + is not supported with openssl. Particularly useful when set to
> "ENG" for
> + authenticating with PKCS#11 tokens, with a PKCS#11 URL in sslCert
> option.
> + See also libcurl `CURLOPT_SSLCERTTYPE`. Can be overridden by the
> + `GIT_SSL_KEY_TYPE` environment variable.
> +
> http.schannelCheckRevoke::
> Used to enforce or disable certificate revocation checks in cURL
> when http.sslBackend is set to "schannel". Defaults to `true` if |
|
This patch series was integrated into seen via git@7422457. |
|
This patch series was integrated into seen via git@c3a6bad. |
|
This patch series was integrated into seen via git@0df38b5. |
|
This patch series was integrated into seen via git@bbb443a. |
|
This patch series was integrated into seen via git@937d47b. |
|
There was a status update in the "Cooking" section about the branch Two configuration variables about SSL authentication material that weren't mentioned in the documentations are now mentioned. Waiting for review response. cf. <[email protected]> source: <[email protected]> |
|
This patch series was integrated into seen via git@5a6605b. |
|
This patch series was integrated into seen via git@430a92d. |
|
This patch series was integrated into seen via git@9023837. |
|
There was a status update in the "Cooking" section about the branch Two configuration variables about SSL authentication material that weren't mentioned in the documentations are now mentioned. Waiting for review response. cf. <[email protected]> source: <[email protected]> |
|
On the Git mailing list, Andrew Carter wrote (reply to this): 0a01d41ee4 (http: add support for different sslcert and sslkey types.,
2023-03-20) added useful SSL config options, but did not document them.
Signed-off-by: Andrew Carter <[email protected]>
---
Documentation/config/http.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt
index a14371b5c9..22a8803dea 100644
--- a/Documentation/config/http.txt
+++ b/Documentation/config/http.txt
@@ -216,6 +216,21 @@ 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.
+ "PEM", "DER" are supported when using openssl or gnutls backends. "P12"
+ is supported on "openssl", "schannel", "securetransport", and gnutls 8.11+.
+ 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"). Only applicable when using "openssl" backend. "DER"
+ is not supported with openssl. Particularly useful when set to "ENG" for
+ authenticating with PKCS#11 tokens, with a PKCS#11 URL in sslCert option.
+ See also libcurl `CURLOPT_SSLKEYTYPE`. Can be overridden by the
+ `GIT_SSL_KEY_TYPE` environment variable.
+
http.schannelCheckRevoke::
Used to enforce or disable certificate revocation checks in cURL
when http.sslBackend is set to "schannel". Defaults to `true` if
--
2.39.5 (Apple Git-154)
|
|
On the Git mailing list, Andrew Carter wrote (reply to this): On 1/30/25 4:22 PM, Junio C Hamano wrote:
> Andrew Carter <[email protected]> writes:
>
>> 0a01d41ee4 (http: add support for different sslcert and sslkey types.,
>> 2023-03-20) added useful SSL config options, but did not document them.
>>
>> Signed-off-by: Andrew Carter <[email protected]>
>> ---
>> Documentation/config/http.txt | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
> warning: Patch sent with format=flowed; space at the end of lines might be lost.
> error: corrupt patch at line 10
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> hint: When you have resolved this problem, run "git am --continue".
> hint: If you prefer to skip this patch, run "git am --skip" instead.
> hint: To restore the original branch and stop patching, run "git am --abort".
> hint: Disable this message with "git config set advice.mergeConflict false"
> Applying: docs: indicate http.sslCertType and sslKeyType
> Patch failed at 0001 docs: indicate http.sslCertType and sslKeyType
>
> I thought that the initial iteration I received from you on Jan 23rd
> was just fine. Did you change some settings with your MUA? The patch
> is heavily whitespace damaged, with full of .
>
>
>> diff --git a/Documentation/config/http.txt b/Documentation/config/http.txt
>> index a14371b5c9..38e874307b 100644
>> --- a/Documentation/config/http.txt
>> +++ b/Documentation/config/http.txt
>> @@ -216,6 +216,21 @@ 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.
>> + "PEM", "DER" are supported when using openssl or gnutls backends. "P12"
>> + is supported on "openssl", "schannel", "securetransport", and
>> gnutls 8.11+.
>> + 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"). Only applicable when using "openssl"
>> backend. "DER"
>> + is not supported with openssl. Particularly useful when set to
>> "ENG" for
>> + authenticating with PKCS#11 tokens, with a PKCS#11 URL in sslCert
>> option.
>> + See also libcurl `CURLOPT_SSLCERTTYPE`. Can be overridden by the
>> + `GIT_SSL_KEY_TYPE` environment variable.
>> +
>> http.schannelCheckRevoke::
>> Used to enforce or disable certificate revocation checks in cURL
>> when http.sslBackend is set to "schannel". Defaults to `true` if
Sorry for the inconvenience, and thanks for your patience.
The original message was composed by GitGitGadget. I pasted the v2 patch into Thunderbird initially, which clearly failed.
I sent a new v2 patch using git send-email, and at a glance it looks unbroken.
If further changes are needed I can get an updated patch to you with a faster turnaround now.
-AC
|
|
On the Git mailing list, Junio C Hamano wrote (reply to this): Andrew Carter <[email protected]> writes:
> On 1/30/25 4:22 PM, Junio C Hamano wrote:
>
>> I thought that the initial iteration I received from you on Jan 23rd
>> was just fine. Did you change some settings with your MUA? The patch
>> is heavily whitespace damaged, with full of .
> ...
> Sorry for the inconvenience, and thanks for your patience.
>
> The original message was composed by GitGitGadget. I pasted the v2
> patch into Thunderbird initially, which clearly failed.
>
> I sent a new v2 patch using git send-email, and at a glance it looks
> unbroken.
>
> If further changes are needed I can get an updated patch to you with a
> faster turnaround now.
Thanks for your patience, too.
E-mailed patch workflow is easy for automation, once set-up
correctly, but there is certain entry cost.
Queued. Let's mark it for 'next'.
|
cc: "brian m. carlson" [email protected]