summaryrefslogtreecommitdiff
path: root/fsck.c
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2020-03-12 01:31:11 -0400
committerLibravatar Jeff King <peff@peff.net>2020-03-12 02:55:24 -0400
commitc716fe4bd917e013bf376a678b3a924447777b2d (patch)
tree3dd97595b4abbbc874446c479773357c25fa1a99 /fsck.c
parentt/lib-credential: use test_i18ncmp to check stderr (diff)
downloadtgif-c716fe4bd917e013bf376a678b3a924447777b2d.tar.xz
credential: detect unrepresentable values when parsing urls
The credential protocol can't represent newlines in values, but URLs can embed percent-encoded newlines in various components. A previous commit taught the low-level writing routines to die() when encountering this, but we can be a little friendlier to the user by detecting them earlier and handling them gracefully. This patch teaches credential_from_url() to notice such components, issue a warning, and blank the credential (which will generally result in prompting the user for a username and password). We blank the whole credential in this case. Another option would be to blank only the invalid component. However, we're probably better off not feeding a partially-parsed URL result to a credential helper. We don't know how a given helper would handle it, so we're better off to err on the side of matching nothing rather than something unexpected. The die() call in credential_write() is _probably_ impossible to reach after this patch. Values should end up in credential structs only by URL parsing (which is covered here), or by reading credential protocol input (which by definition cannot read a newline into a value). But we should definitely keep the low-level check, as it's our final and most accurate line of defense against protocol injection attacks. Arguably it could become a BUG(), but it probably doesn't matter much either way. Note that the public interface of credential_from_url() grows a little more than we need here. We'll use the extra flexibility in a future patch to help fsck catch these cases.
Diffstat (limited to 'fsck.c')
0 files changed, 0 insertions, 0 deletions