summaryrefslogtreecommitdiff
path: root/examples/commit.c
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2020-01-31 08:49:34 +0100
committerPatrick Steinhardt <ps@pks.im>2020-01-31 15:25:47 +0100
commit93a9044ff663684da278d4d0fc5111a293e6555b (patch)
tree679f958f06811c1ae0d8e5188ef65f6d334d090b /examples/commit.c
parenta1bff63bf1097e08c9ee1843650279054ddd2ea9 (diff)
downloadlibgit2-93a9044ff663684da278d4d0fc5111a293e6555b.tar.gz
fetchhead: strip credentials from remote URL
If fetching from an anonymous remote via its URL, then the URL gets written into the FETCH_HEAD reference. This is mainly done to give valuable context to some commands, like for example git-merge(1), which will put the URL into the generated MERGE_MSG. As a result, what gets written into FETCH_HEAD may become public in some cases. This is especially important considering that URLs may contain credentials, e.g. when cloning 'https://foo:bar@example.com/repo' we persist the complete URL into FETCH_HEAD and put it without any kind of sanitization into the MERGE_MSG. This is obviously bad, as your login data has now just leaked as soon as you do git-push(1). When writing the URL into FETCH_HEAD, upstream git does strip credentials first. Let's do the same by trying to parse the remote URL as a "real" URL, removing any credentials and then re-formatting the URL. In case this fails, e.g. when it's a file path or not a valid URL, we just fall back to using the URL as-is without any sanitization. Add tests to verify our behaviour.
Diffstat (limited to 'examples/commit.c')
0 files changed, 0 insertions, 0 deletions