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

[M Hickford <mirth.hickford@gmail.com>]

On Mon, 8 Apr 2024 at 19:43, Jackson Toeniskoetter <jackdt@google.com> 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@crustytoothpaste.net/,
> 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.