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@xxxxxxxxxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
