From: Jeff King <peff@peff.net>
To: John Szakmeister <john@szakmeister.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH v2 0/2] http: store credential when PKI auth is used
Date: Thu, 11 Mar 2021 20:31:20 -0500 [thread overview]
Message-ID: <YErEaJ25gY8dzErv@coredump.intra.peff.net> (raw)
In-Reply-To: <20210312004842.30697-1-john@szakmeister.net>
On Thu, Mar 11, 2021 at 07:48:40PM -0500, John Szakmeister wrote:
> Here's my second attempt at getting the certificate password into the credential
> store. I tested from a working PKI setup and found curl--at least reasonable
> recent versions of it--return CURLE_SSL_CERTPROBLEM:
>
> CURLE_SSL_CERTPROBLEM (58)
> problem with the local client certificate.
>
> It appears there could be another possible error from curl:
>
> CURLE_SSL_CONNECT_ERROR (35)
> A problem occurred somewhere in the SSL/TLS handshake. You
> really want the error buffer and read the message there as it
> pinpoints the problem slightly more. Could be certificates (file
> formats, paths, permissions), passwords, and others.
>
> This seems less likely to be a bad client password scenario, so I did not look
> for this particular error to reject it.
>
> I also added one other small patch to remove the check of a non-empty password
> before calling credential_store() for proxy_auth, as credential_store() already
> checks for a non-empty password and gracefully handles it when it doesn't.
Thanks. Both patches look good to me. I wondered briefly if we needed to
worry about old versions of curl missing CURLE_SSL_CERTPROBLEM. But it
seems to have shown up in ~2002, so I think we are fine to assume it's
there.
It would be nice if we had some tests here, but we currently do not
cover any of the ssl-cert stuff in the test suite. I suspect adding them
would be a big pain to configure and maintain, so I'm OK to leave it off
for now. Hopefully you gave it some basic manual testing with your
working setup (good password is stored, bad password is rejected).
Looking at how we generate the server-side cert for our http tests, we
could _probably_ do something similar for a client-side cert, and just
configure the server to accept a self-signed certificate. But like I
said, I'm OK to leave that for another series (though of course if you
want to work on it, that would be very much appreciated).
-Peff
next prev parent reply other threads:[~2021-03-12 1:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 0:48 [PATCH v2 0/2] http: store credential when PKI auth is used John Szakmeister
2021-03-12 0:48 ` [PATCH v2 1/2] " John Szakmeister
2021-03-12 0:58 ` Junio C Hamano
2021-03-12 1:41 ` brian m. carlson
2021-03-12 1:45 ` Jeff King
2021-03-12 2:27 ` John Szakmeister
2021-03-12 0:48 ` [PATCH v2 2/2] http: drop the check for an empty proxy password before approving John Szakmeister
2021-03-12 1:31 ` Jeff King [this message]
2021-03-12 2:37 ` [PATCH v2 0/2] http: store credential when PKI auth is used John Szakmeister
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=YErEaJ25gY8dzErv@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@szakmeister.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).