summaryrefslogtreecommitdiff
path: root/git-gui/lib/commit.tcl
diff options
context:
space:
mode:
authorJohannes Schindelin <johannes.schindelin@gmx.de>2024-11-04 14:48:22 +0100
committerJohannes Schindelin <johannes.schindelin@gmx.de>2024-11-26 20:24:04 +0100
commitb01b9b81d36759cdcd07305e78765199e1bc2060 (patch)
tree1b1ef503233ddfcb23686e0cd415f008bf35631a /git-gui/lib/commit.tcl
parent7725b8100ffbbff2750ee4d61a0fcc1f53a086e8 (diff)
credential: disallow Carriage Returns in the protocol by default
While Git has documented that the credential protocol is line-based, with newlines as terminators, the exact shape of a newline has not been documented. From Git's perspective, which is firmly rooted in the Linux ecosystem, it is clear that "a newline" means a Line Feed character. However, even Git's credential protocol respects Windows line endings (a Carriage Return character followed by a Line Feed character, "CR/LF") by virtue of using `strbuf_getline()`. There is a third category of line endings that has been used originally by MacOS, and that is respected by the default line readers of .NET and node.js: bare Carriage Returns. Git cannot handle those, and what is worse: Git's remedy against CVE-2020-5260 does not catch when credential helpers are used that interpret bare Carriage Returns as newlines. Git Credential Manager addressed this as CVE-2024-50338, but other credential helpers may still be vulnerable. So let's not only disallow Line Feed characters as part of the values in the credential protocol, but also disallow Carriage Return characters. In the unlikely event that a credential helper relies on Carriage Returns in the protocol, introduce an escape hatch via the `credential.protectProtocol` config setting. This addresses CVE-2024-52006. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Diffstat (limited to 'git-gui/lib/commit.tcl')
0 files changed, 0 insertions, 0 deletions