Re: Bare repositories in the working tree are a security risk
- From
Glen Choo <chooglen@google.com>
- Date
- Apr 15, 2022, 23:59 UTC
- Message-ID
- <kl6l35id99ue.fsf@chooglen-macbookpro.roam.corp.google.com>
- In-Reply-To
- <kl6l5yn99ahv.fsf@chooglen-macbookpro.roam.corp.google.com>
Show 15 quoted lines
> I wonder if all we need to do is make setup.c a little smarter - we > recognize bare repos, but *only* if they are contained in a directory > named `.git/`. This should fix "git init" I think, because even though > we'd ignore "./ (bare)", we'd recognize `../.git/` and we get the right > behavior again. > > > It is a separate matter if it makes sense to allow creating a new > > repository inside a bare repository (it does---that is what the > > modern submodule layout uses), or to allow an alias to help doing so > > defined in the top-level bare repository (it probably does---the > > end-user may want to have a handy way to customize how submodules > > are configured). But it seems to tell us that with today's external > > interface we have for "git init", we cannot take configuration from > > a shallower level and use it to drive "git init" to create a new > > repository at a deeper level.
Hah, I forgot that submodules are stored as `.git/modules/foo` and not `.git/modules/foo/.git`, so this doesn't preserve the existing behavior for submodules nested > 1 level.