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