Re: Bare repositories in the working tree are a security risk

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2022, 18:47 UTC
Message-ID: <xmqq4k2mi88p.fsf@gitster.g>
In-Reply-To: <CAJoAoZkf6VuAOwX9j8Zc0x4HqJRJ5zQgqfmu+8Zs1kVx88dGpg@mail.gmail.com>

Emily Shaffer <emilyshaffer@google.com> writes:

Show 13 quoted lines

>> Nice - a more strict spin on proposal 3 from above, if I understand it
>> right. Rather than allowing any and all bare repos, avoid someone
>> sneaking in a malicious one next to legitimate ones by using an
>> allowlist. Seems reasonable to me.
>
> Ah, another thing I forgot to mention. There has been a little
> discussion in the past about isolating "safe" parts of config (and
> gitdir) from "unsafe" parts, e.g. "which configs and embedded scripts
> are executables", to help better protect from zipfile-type attacks,
> which are very similar to this kind of attack. I wonder if it makes
> sense to consider that sort of thing as a needswork for this bugfix?
> e.g. "/* NEEDSWORK: Only ignore unsafe configs and hooks instead of
> ignoring the entire embedded config and hooks in the future */"?

There have been such discussions in the past and they all went nowhere because such safe-listing fundamentally does not work. What you consider "safe" today may turn out to be "unsafe" and in a later version of Git will stop honoring it, and for those who depended on it being listed as "safe", such a security fix will be a regression.

Disabling the whole thing if the file can be tainted is the only sensible way forward without promising users that they will be hurt by such changes/regressions in the future, I would think.

So, no, I do not think such a NEEDSWORK comment is welcome.

Thanks.