On Wed, May 15 2019, Martin Langhoff wrote: > Spotted this on the internet... > > https://github.blog/2019-05-14-git-ransom-campaign-incident-report/ > > Haven't hacked on git for a while, and I am not affiliated with any of > the stakeholders. However, reading it, I wanted to slam my head on the > desk. > > IIRC, git will sanely store a password elsewhere if it gets to prompt > for it. Should we be trying to unpack usernames/passwords from HTTP > urls, and DTRT with them? > > Are there other ways this could be made better? I think we should do nothing. The linked blog post really manages to bury the lead. I guess you'll get that when PR at three different companies gets a say. For those looking for a brief summary, here's mine: Some people using git hosting sites "git clone"'d https URLs to their repos with username/passwords in them. They then pointed a webserver at their checked-out directory, and got pwned by someone scraping "/.git/config" from public websites looking for credentials. Trying to mitigate this in git is just going to annoy users who are doing this in the context of an otherwise secure workflow. The users who were affected by this are probably also the sort of users who are hardcoding their AWS password in some JavaScript checked into their project or whatever, there's only so much you can do. It's probably more productive to say convince whoever maintains the default nginx/apache etc. docker image to default to some Fisher-Price mode where dotfiles aren't served up by default. Or, for GitLab/GitHub etc. to discourage use of https API tokens in favor of SSH deploy keys. OpenSSH goes out of its way to not allow you to provide paswords in URLs, on the command-line etc. in anticipation of exactly this sort of scenario. Even then I've seen users write say docker images where they manage to hardcode an SSH private key in a public image out of convenience or lazyness (say needing "git clone" something during the image build).
