Re: Git ransom campaign incident report - May 2019

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 17, 2019, 23:13 UTC
Message-ID: <CACPiFC+=co2-yGwoiKqr1qSu8dLmVQZ5NxfbdwOr7xz=a7xpdA@mail.gmail.com>
In-Reply-To: <20190517222031.GA17966@sigill.intra.peff.net>

On Fri, May 17, 2019 at 6:20 PM Jeff King <peff@peff.net> wrote:

> I hate the magical-ness of 3b, because credential-store really _isn't_
> the best choice. It's just better than the current behavior. At the same
> time, by doing it automatically, the existing flow they were using just
> works, and is moderately better.

Quite a bit better. It sits in a different directory, and with tight permissions.

Overall -- thank you! That's the process I was picturing. Even just scrubbing the credentials -- your "step 1" -- would be a significant improvement, if a bit unfriendly.

Show 6 quoted lines

> > 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.
>
> Yes, that's definitely the way you _should_ do it. I think the problem

The key thing are the credentials, and there are much better solutions for this -- ssh keys, etc.

This isn't for thoughtful users, this is to save unaware users from themselves. Maybe they'll and hurt themselves with something else, but that's part of removing sharp edges from a product.

cheers,

--
 martin.langhoff@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff