diff options
author | Jeff King <peff@peff.net> | 2020-03-12 01:31:11 -0400 |
---|---|---|
committer | Jeff King <peff@peff.net> | 2020-03-12 02:55:24 -0400 |
commit | c716fe4bd917e013bf376a678b3a924447777b2d (patch) | |
tree | 3dd97595b4abbbc874446c479773357c25fa1a99 /builtin/unpack-file.c | |
parent | t/lib-credential: use test_i18ncmp to check stderr (diff) | |
download | tgif-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 'builtin/unpack-file.c')
0 files changed, 0 insertions, 0 deletions