git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git ransom campaign incident report - May 2019

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
May 17, 2019, 19:39 UTC
Message-ID
<nycvar.QRO.7.76.6.1905172121130.46@tvgsbejvaqbjf.bet>
In-Reply-To
<20190516042739.GH4596@sigill.intra.peff.net>
Hi,
On Thu, 16 May 2019, Jeff King wrote:
Show 33 quoted lines
> On Wed, May 15, 2019 at 08:59:47PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> >
> > 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.
>
> I think so, too.
>
> But just brainstorming, one thing we _could_ do is issue a warning when
> we see a password in a URL and say "hey, what you're doing isn't
> fantastic; considering using a credential helper".
>
> Of course I suspect there are many cases where people _do_ need to store
> the password in plaintext, because an automated system needs to fetch
> with it. They can use the plaintext git-credential-store, but it's
> slightly more hassle. And it doesn't really _solve_ the problem (though
> perhaps it would be harder to accidentally expose it with your web
> server!).

One thing that we actually *could* do here is to anonymize the URLs stored under remote.origin.url when cloning. In no other circumstance that I can think of do we take an URL from some command-line parameter that is not *explicitly* intended for storing in the config.

Combined with that warning "You cloned via a URL that contains credentials; for security reasons, the credentials were scrubbed before storing this in your Git config. Please consider using a credential manager instead of storing secrets in your Git config." this should provide a reasonable compromise.

Judging from looking at my own automated jobs, it does not appear that you would *ever* need to store such credentials in the Git config, anyway. If you need to, say, push to a repository, you can always store the full URL (or the credentials) in a secret variable.

Ciao, Dscho

Previous: Jeff KingNext: Jeff King
Message 4 of 23 in “Git ransom campaign incident report - May 2019”
  1. Martin LanghoffMay 15, 2019
  2. Ævar Arnfjörð BjarmasonMay 15, 2019
  3. Jeff KingMay 16, 2019
  4. Johannes SchindelinMay 17, 2019
  5. Jeff KingMay 17, 2019
  6. Martin LanghoffMay 17, 2019
  7. Jeff KingMay 19, 2019
  8. 1/3 transport_anonymize_url(): support retaining usernameJeff King, May 19, 2019
  9. Eric SunshineMay 19, 2019
  10. René ScharfeMay 20, 2019
  11. Johannes SchindelinMay 20, 2019
  12. Johannes SchindelinMay 20, 2019
  13. 2/3 clone: avoid storing URL passwords in configJeff King, May 19, 2019
  14. 3/3 clone: auto-enable git-credential-store when necessaryJeff King, May 19, 2019
  15. Eric SunshineMay 20, 2019
  16. Jeff KingMay 20, 2019
  17. Johannes SchindelinMay 20, 2019
  18. Ævar Arnfjörð BjarmasonMay 20, 2019
  19. Jeff KingMay 20, 2019
  20. Ævar Arnfjörð BjarmasonMay 20, 2019
  21. Jeff KingMay 20, 2019
  22. Ævar Arnfjörð BjarmasonMay 20, 2019
  23. Johannes SchindelinMay 20, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.