Re: [PATCH 00/13] Support for arbitrary schemes in credentials

From: Calvin Wan <calvinwan@google.com>
Date: Apr 2, 2024, 22:26 UTC
Message-ID: <20240402222619.2212650-1-calvinwan@google.com>
In-Reply-To: <20240324011301.1553072-1-sandals@crustytoothpaste.net>

Hi Brian,

While I personally do not know the specifics of how Git authentication works at Google, I am passing this series along to the team that does own Git authentication (adding Jackson to this reply).

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 11 quoted lines

> Right now, HTTP authentication in Git is mostly limited to approaches
> that require a username and password or are Kerberos (GSSAPI).  In
> addition, we effectively require that libcurl (or, for other software,
> such as Git LFS, using the credential helper, that HTTP library) knows
> how to implement the authentication scheme.
> 
> However, this poses two sets of problems.  First, some sites, such as
> Azure DevOps, want to use Bearer authentication, which we don't support.
> This is implemented using `http.extraHeader`, which is not a secure way
> to store credentials, since our credential helper protocol does not
> support this functionality.

My first thought was if using `http.extraHeader` is insecure as you claim and we use that internally, then how do we ensure that it is secure? Or are you claiming that using `http.extraHeader` out of the box without an additional security layer is insecure?

Thanks, Calvin