On Mon, 8 Apr 2024 at 19:43, Jackson Toeniskoetter <jackdt@xxxxxxxxxx> wrote: > > Just to clarify, we at Google do not use extraheader to pass along > credentials. Instead we use the .gitcookies file[1], which iiuc gets > read by the git process directly. I'm not a security expert but I > imagine the risk surface of extraheader and .gitcookies is similar. Hi Jackson. To clarify, are you describing hosts *.googlesource.com such as https://go.googlesource.com/? It always confused me that the 'generate password' feature gives you something different to a password. https://www.googlesource.com/new-password https://gerrit-review.googlesource.com/Documentation/user-upload.html Have you tried OAuth credential helper git-credential-oauth https://github.com/hickford/git-credential-oauth? It can authenticate to *.googlesource.com without setup. OAuth has security advantages over .gitcookies because the OAuth access tokens expire after 2 hours and the OAuth refresh tokens are single use. These credentials are stored in the user's choice of secure storage such as git-credential-cache, git-credential-libsecret, git-credential-wincred or git-credential-osxkeychain. I encourage you to try it out. You'll need a local web browser because Google's OAuth configuration currently forbids device authorization grant for the relevant scope https://issues.gerritcodereview.com/issues/300279941 > > Reading your post on > https://lore.kernel.org/git/20240324011301.1553072-1-sandals@xxxxxxxxxxxxxxxxxxxx/, > it's unclear to me why the credential helper protocol needs to be > updated. If the goal is to support Bearer tokens, can that not just be > implemented using extraheader? It seems like the goal of getting > credentials out of the config file can be accomplished without > updating the credential helper protocol. So is the bigger goal to > support more robust and modern auth schemes which require multiple > steps? That would be useful to Google; multi-step auth would probably > be a more elegant way for us to stop using .gitcookies than other > solutions we were considering. > > [1] This is actually only for external contributors. Google employees > have a more robust authentication mechanism. Concerns have been raised > internally about our usage of gitcookies, but it hasn't been made a > priority to address because a leaked credential would not allow an > attacker to commit bad code, only read it or initiate a code review.
