All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav M <stanislav.malishevskiy@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Stanislav Malishevskiy via GitGitGadget <gitgitgadget@gmail.com>,
	Todd Zullinger <tmz@pobox.com>,
	git@vger.kernel.org,
	Stanislav Malishevskiy <s.malishevskiy@auriga.com>
Subject: Re: [PATCH v2] http: add support for different sslcert and sslkey types.
Date: Mon, 20 Mar 2023 21:21:44 +0300	[thread overview]
Message-ID: <CAEpdKf=THU=sc3S3W4azBmYp7+J945GxFqhh_i-5kV0kunMdNw@mail.gmail.com> (raw)
In-Reply-To: <20230320171051.GA2615782@coredump.intra.peff.net>

> > @@ -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 <peff@peff.net>:
>
> On Mon, Mar 20, 2023 at 03:48:49PM +0000, Stanislav Malishevskiy via GitGitGadget wrote:
>
> > From: Stanislav Malishevskiy <s.malishevskiy@auriga.com>
> >
> > 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:
>
> >  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/
>
> 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.
>
> > @@ -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

  reply	other threads:[~2023-03-20 18:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-19 13:51 [PATCH] That change for support different sslcert and sslkey types Stanislav Malishevskiy via GitGitGadget
2023-03-20 15:48 ` [PATCH v2] http: add support for " Stanislav Malishevskiy via GitGitGadget
2023-03-20 17:10   ` Jeff King
2023-03-20 18:21     ` Stanislav M [this message]
2023-03-21 17:22       ` Jeff King
2023-03-20 17:23   ` Junio C Hamano
2023-03-20 18:24     ` Stanislav M
2023-03-21 17:22     ` Jeff King
2023-03-21 17:43       ` Junio C Hamano
2023-03-23  9:33         ` Stanislav M
2023-03-23 18:01           ` Jeff King
2023-03-23 18:16             ` Stanislav M
2023-03-29 18:53               ` Junio C Hamano
2023-03-29 19:22                 ` Stanislav M
2023-03-29 23:23                 ` Jeff King
2023-03-30  0:20                   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEpdKf=THU=sc3S3W4azBmYp7+J945GxFqhh_i-5kV0kunMdNw@mail.gmail.com' \
    --to=stanislav.malishevskiy@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=peff@peff.net \
    --cc=s.malishevskiy@auriga.com \
    --cc=tmz@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.