Re: status on security of embedded repos?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 6, 2022, 13:56 UTC
Message-ID: <4697o162-0pop-4715-150r-2317p0n69581@tzk.qr>
In-Reply-To: <c209dc21f6826bbb60d75450e6f7f9ff2258d18c.camel@scientia.org>

Hi Chris,

answers inline.

On Mon, 5 Sep 2022, Christoph Anton Mitterer wrote:

> Is it known whether this will automatically prevent the issue also for
> any 3rd party modules for git?

As long as they use the core Git CLI at a new-enough version: yes.

But libgit2 and JGit, two separate Git implementations that are in wide use, too, probably do not have support for this.

In other words, users of libgit2 & JGit will likely be unaffected by setting `safe.bareRepository` and sill still need to take manual precautions.

If you are using applications based on those projects, you might be interested in porting support for `safe.bareRepository` to those projects and contribute the enhancement.

Show 8 quoted lines

> I mean is special action needed by them to consider the option? Or is
> it likely that there are some which manually discover the git config
> and could thereby still suffer from the vulnerability.
>
>
> I assume the same wouldn't be possible for non-bare embedded repos? I
> tried to try this, but when git add(ing) such repo, it already warns
> that the embedded (non-bare) repo would not be included in clones.

Yes, indeed, `.git` entries in Git's tree objects are forbidden.

Ciao, Johannes

Show 14 quoted lines

> On Mon, 2022-09-05 at 12:21 +0200, Johannes Schindelin wrote:
> > Note: The default will still be at `safe.bareRepository = all`.
>
> That seems like a not so secure default, given that probably only few
> people will ever encounter embedded bare repos.
>
> OTOH, the attack surface seems rather big, if one just needs to clone
> some arbitrary repo where one wants to look at some code, and is then
> in principle already fully vulnerable?!
>
>
> Thanks,
> Chris.
>