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. [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.
