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

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

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

On 2024-04-08 at 18:42:56, Jackson Toeniskoetter 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.
> 
> 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.

Bearer authentication certainly can be implemented using
http.extraheader and the config file is also not a secure way to store
credentials, which is why the credential helper protocol is being
updated, since then people will be able to store the credentials in a
password manager or other secure store.  Other HTTP schemes will also be
supported as long as they don't require headers other than Authorization
and the credential helper can implement them on behalf of Git.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

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