git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Git ransom campaign incident report - May 2019
Date: Wed, 15 May 2019 20:59:47 +0200	[thread overview]
Message-ID: <8736lfwnks.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CACPiFCJdXsrywra8qPU3ebiiGQP3YPC6g-_Eohbfwu_bQgfyVg@mail.gmail.com>


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).

  reply	other threads:[~2019-05-15 18:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15 17:49 Git ransom campaign incident report - May 2019 Martin Langhoff
2019-05-15 18:59 ` Ævar Arnfjörð Bjarmason [this message]
2019-05-16  4:27   ` Jeff King
2019-05-17 19:39     ` Johannes Schindelin
2019-05-17 22:20       ` Jeff King
2019-05-17 23:13         ` Martin Langhoff
2019-05-19  5:07         ` Jeff King
2019-05-19  5:10           ` [PATCH 1/3] transport_anonymize_url(): support retaining username Jeff King
2019-05-19 23:28             ` Eric Sunshine
2019-05-20 16:14             ` René Scharfe
2019-05-20 16:36             ` Johannes Schindelin
2019-05-20 16:43             ` Johannes Schindelin
2019-05-19  5:12           ` [PATCH 2/3] clone: avoid storing URL passwords in config Jeff King
2019-05-19  5:16           ` [PATCH 3/3] clone: auto-enable git-credential-store when necessary Jeff King
2019-05-20 11:28             ` Eric Sunshine
2019-05-20 12:31               ` Jeff King
2019-05-20 16:48                 ` Johannes Schindelin
2019-05-20 13:56             ` Ævar Arnfjörð Bjarmason
2019-05-20 14:08               ` Jeff King
2019-05-20 15:17                 ` Ævar Arnfjörð Bjarmason
2019-05-20 15:24                   ` Jeff King
2019-05-20 17:08             ` Ævar Arnfjörð Bjarmason
2019-05-20 14:43           ` Git ransom campaign incident report - May 2019 Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8736lfwnks.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=martin.langhoff@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).