All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Emily Shaffer <emilyshaffer@google.com>
Cc: "Taylor Blau" <me@ttaylorr.com>,
	"Glen Choo" <chooglen@google.com>,
	"Git List" <git@vger.kernel.org>,
	justin@justinsteven.com,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Derrick Stolee" <derrickstolee@github.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	"Randall S. Becker" <rsbecker@nexbridge.com>,
	"Martin von Zweigbergk" <martinvonz@google.com>
Subject: Re: Bare repositories in the working tree are a security risk
Date: Thu, 21 Apr 2022 17:22:04 -0400	[thread overview]
Message-ID: <YmHK/GJ3qa7QuVUD@nand.local> (raw)
In-Reply-To: <CAJoAoZnd=BKycr0c71-BQJyO3zoymC7p++Zke+OSkV4neweAOQ@mail.gmail.com>

On Thu, Apr 21, 2022 at 02:01:44PM -0700, Emily Shaffer wrote:
> I don't think there is much reason to continue searching above the
> first found '.git' because we disallow '.git' from being committed or
> checked out, right? So this extra filesystem hunting and ceiling math
> seems unnecessary to me. I know I am slightly allergic to searching
> the filesystem for a parent repo to begin with, so I'm sure I've got
> some bias here ;)

Right; once we find a non-bare embedding repository we should absolutely
stop our search. I was suggesting we could stop our search earlier for
environments that use non-embedded bare repositories with a fairly deep
directory structure.

E.g., if you store lots of bare repositories in /data/repositories and
you know that none of them are embedded, we could quickly determine
whether or not the cwd is a descendent of /data/repositories and avoid
the search entirely if so.

> > We'd probably want to allow saying "all embedded bare repositories are
> > safe to read config/hooks from", too. I hadn't considered this approach
> > as a way to read some embedded repos and not others; I suspect the
> > overwhelmingly common use-case would be: `git config --local
> > safe.embeddedRepo '*'`.
>
> Ah, I dislike this option for the exact reason I mentioned - avoiding
> a malicious repo being snuck in next to legitimate repos. I'd prefer
> to rely on exact matching only - but as the config needs to be set by
> every contributor every time the set of bare repos changes, that
> sounds impossible to manage for a project which may be constantly
> adding and removing these repos.

I share your distaste for this sort of thing, but I think we have to
recognize that there are likely to be many repos that embed dozens or
more bare repos inside of them, and asking them to opt-in each one
individually seems like a fairly large request for Git to make of them.

> That said.... I'm biased again, but if you want to be certain of the
> state of another repository in order to run tests in it... why not use
> a submodule for that repository? Not a helpful comment for those
> already using embedded bare repos, though ;)

Exactly, re: your last sentence.

> Thanks for the food for thought.

Ditto!

Thanks,
Taylor

  reply	other threads:[~2022-04-21 21:22 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06 22:43 Bare repositories in the working tree are a security risk Glen Choo
2022-04-06 23:22 ` [PATCH] fsck: detect bare repos in trees and warn Glen Choo
2022-04-07 12:42   ` Johannes Schindelin
2022-04-07 13:21     ` Derrick Stolee
2022-04-07 14:14       ` Ævar Arnfjörð Bjarmason
2022-04-14 20:02         ` Glen Choo
2022-04-15 12:46           ` Ævar Arnfjörð Bjarmason
2022-04-07 15:11       ` Junio C Hamano
2022-04-13 22:24       ` Glen Choo
2022-04-07 13:12   ` Ævar Arnfjörð Bjarmason
2022-04-07 15:20   ` Junio C Hamano
2022-04-07 18:38 ` Bare repositories in the working tree are a security risk John Cai
2022-04-07 21:24 ` brian m. carlson
2022-04-07 21:53   ` Justin Steven
2022-04-07 22:10     ` brian m. carlson
2022-04-07 22:40       ` rsbecker
2022-04-08  5:54       ` Junio C Hamano
2022-04-14  0:03         ` Junio C Hamano
2022-04-14  0:04         ` Glen Choo
2022-04-13 23:44       ` Glen Choo
2022-04-13 20:37 ` Glen Choo
2022-04-13 23:36   ` Junio C Hamano
2022-04-14 16:41     ` Glen Choo
2022-04-14 17:35       ` Junio C Hamano
2022-04-14 18:19         ` Junio C Hamano
2022-04-15 21:33         ` Glen Choo
2022-04-15 22:17           ` Junio C Hamano
2022-04-16  0:52             ` Taylor Blau
2022-04-15 22:43           ` Glen Choo
2022-04-15 20:13       ` Junio C Hamano
2022-04-15 23:45         ` Glen Choo
2022-04-15 23:59           ` Glen Choo
2022-04-16  1:00           ` Taylor Blau
2022-04-16  1:18             ` Junio C Hamano
2022-04-16  1:30               ` Taylor Blau
2022-04-16  0:34 ` Glen Choo
2022-04-16  0:41 ` Glen Choo
2022-04-16  1:28   ` Taylor Blau
2022-04-21 18:25     ` Emily Shaffer
2022-04-21 18:29       ` Emily Shaffer
2022-04-21 18:47         ` Junio C Hamano
2022-04-21 18:54           ` Taylor Blau
2022-04-21 19:09       ` Taylor Blau
2022-04-21 21:01         ` Emily Shaffer
2022-04-21 21:22           ` Taylor Blau [this message]
2022-04-29 23:57     ` Glen Choo
2022-04-30  1:14       ` Taylor Blau
2022-05-02 19:39         ` Glen Choo
2022-05-02 14:05       ` Philip Oakley
2022-05-02 18:50         ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=YmHK/GJ3qa7QuVUD@nand.local \
    --to=me@ttaylorr.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=chooglen@google.com \
    --cc=derrickstolee@github.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=justin@justinsteven.com \
    --cc=martinvonz@google.com \
    --cc=rsbecker@nexbridge.com \
    --cc=sandals@crustytoothpaste.net \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.