From: <rsbecker@nexbridge.com>
To: "'Quentin Bouget'" <ypsah@devyard.org>, <git@vger.kernel.org>
Subject: RE: [PATCH 2/2] http: prevent redirect from dropping credentials during reauth
Date: Sun, 4 Feb 2024 18:01:53 -0500 [thread overview]
Message-ID: <017a01da57be$28748aa0$795d9fe0$@nexbridge.com> (raw)
In-Reply-To: <20240204185427.39664-3-ypsah@devyard.org>
On Sunday, February 4, 2024 1:54 PM, Quentin Bouget wrote:
>During a re-authentication (second attempt at authenticating with a remote,
e.g.
>after a failed GSSAPI attempt), git allows the remote to provide credential
overrides
>in the redirect URL and unconditionnaly drops the current HTTP credentials
in favors
>of those, even when there aren't any.
>
>This commit makes it so HTTP credentials are only overridden when the
redirect URL
>actually contains credentials itself.
>
>Signed-off-by: Quentin Bouget <ypsah@devyard.org>
>---
> http.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
>diff --git a/http.c b/http.c
>index ccea19ac47..caba9cac1e 100644
>--- a/http.c
>+++ b/http.c
>@@ -2160,7 +2160,25 @@ static int http_request_reauth(const char *url,
> if (options && options->effective_url && options->base_url) {
> if (update_url_from_redirect(options->base_url,
> url, options->effective_url)) {
>+ char *username = NULL, *password = NULL;
>+
>+ if (http_auth.username)
>+ username = xstrdup(http_auth.username);
>+ if (http_auth.password)
>+ password = xstrdup(http_auth.password);
>+
> credential_from_url(&http_auth,
options->base_url->buf);
>+
>+ if (http_auth.username)
>+ free(username);
>+ else if (username)
>+ http_auth.username = username;
>+
>+ if (http_auth.password)
>+ free(password);
>+ else if (password)
>+ http_auth.password = password;
>+
> url = options->effective_url->buf;
> }
> }
I am wondering whether this is a good idea. Having credentials in a redirect
seems like it might be a vector for going somewhere other than what you want
to do, with credentials you do not necessarily want. Others might no better
than I on this, but would potentially lead to a CVE? I would prefer to see
credentials in a redirect rejected rather than used.
--Randall
next prev parent reply other threads:[~2024-02-04 23:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-04 18:54 [PATCH 0/2] Fix gitlab's token-based authentication w/ kerberos Quentin Bouget
2024-02-04 18:54 ` [PATCH 1/2] http: only reject basic auth credentials once they have been tried Quentin Bouget
2024-02-04 22:47 ` Junio C Hamano
2024-02-05 3:03 ` Quentin Bouget
2024-02-05 5:47 ` Patrick Steinhardt
2024-02-04 18:54 ` [PATCH 2/2] http: prevent redirect from dropping credentials during reauth Quentin Bouget
2024-02-04 22:36 ` brian m. carlson
2024-02-05 3:01 ` Quentin Bouget
2024-02-05 22:18 ` brian m. carlson
2024-02-05 22:52 ` rsbecker
2024-02-04 22:51 ` Junio C Hamano
2024-02-05 3:06 ` Quentin Bouget
2024-02-04 23:01 ` rsbecker [this message]
2024-02-05 3:12 ` Quentin Bouget
2024-02-05 9:22 ` Robert Coup
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='017a01da57be$28748aa0$795d9fe0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git@vger.kernel.org \
--cc=ypsah@devyard.org \
/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).