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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3275 bytes --]

On 2024-04-02 at 22:26:19, Calvin Wan wrote:
> 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:
> > 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?

Storing plaintext credentials on disk is just not a good idea, and it's
not a secure way to store them.  This is why `.netrc` is a less than
great idea, but for Git, it's also possible to have a shared repository
where information in `.git/config` can leak, and sometimes people also
just expose Git repositories accidentally over HTTP (say, on websites)
and leak all of their config.  Sometimes people put `http.extraheader`
in `~/.gitconfig` and then check it into their public dotfiles, and then
push it to GitHub, for example.

It's a little less of a problem if it's a personal laptop and nobody
else uses it, but it's still a lot easier to accidentally expose an
arbitrary file or for an attack to exfiltrate an existing file (just
through a bug in existing software) than it is to necessarily execute
the arbitrary code necessary to read the data out of the system
credential store.

`http.extraheader` for Authorization headers usually necessitates that
the data is either stored in the config file or passed on the command
line, and that's why it's insecure.  Certainly, you could configure it
to read only from the environment using `--config-env` or you could
configure your system to store the data in the config only with a
single, highly restricted service account and it might be okay.

The kind of usage of `http.extraheader` that's likely to be fine is just
passing an extra header that some broken proxy needs to be satisfied,
like setting a specific language or faking a header that the proxy needs
to think Git's a web browser (since, of course, if it's not Internet
Explorer, it's insecure).  As long as you're not storing credentials or
secrets in `http.extraheader`, I have no objections.

I don't know what you're using it for at Google, but of course if it is
Authorization headers, then I'm hoping this series will help you avoid
needing to do that.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]