From: Taylor Blau <me@ttaylorr.com>
To: Glen Choo <chooglen@google.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>,
justin@justinsteven.com, martinvonz@google.com,
"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: Bare repositories in the working tree are a security risk
Date: Fri, 15 Apr 2022 21:00:06 -0400 [thread overview]
Message-ID: <YloVFn0SC/SF33b3@nand.local> (raw)
In-Reply-To: <kl6l5yn99ahv.fsf@chooglen-macbookpro.roam.corp.google.com>
On Fri, Apr 15, 2022 at 04:45:32PM -0700, Glen Choo wrote:
> However, this case shows that --git-dir won't work at all with "git
> init", and I wouldn't be surprised if there are other breakages hiding
> just out of plain sight. This worries me a lot more, and I think
> disabling bare repo detection wholesale might be a nonstarter.
>
> 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.
>
> I haven't tested it yet, but this proposal sounds like it has quite a
> few merits to me:
>
> - Easy to explain.
> - Easy rationalization ("We used to be quite cavalier about detecting
> bare repos, but now we're being more strict by default").
> - Fixes the embedded bare repo problem (since we don't allow .git).
> - No-op and neglible performance hit for non-bare repo users, even if
> they occasionally run "git" inside ".git".
>
> As with the original proposal of "ignore bare repos altogether", this
> will still be a headache for bare repo users (unless they don't mind
> renaming their bare repo directory to ".git"), so this behavior needs to
> be configurable, but perhaps the fallout is small enough that this
> could be a safe default.
I think you are underestimating the fallout, at least if I'm
understanding your proposal correctly.
Is the proposal to only detect bare repositories that are called `.git`?
I think that's what you're suggesting, though can't we just as easily
embed a bare repository named ".git" in a clone as long as its not in
the root directory?
But like I said in an earlier message, I think that this is vastly
underestimating the number of legitimate repositories that are stored as
bare repos on disk (not embedded in a non-bare repo, nor named ".git").
Thanks,
Taylor
next prev parent reply other threads:[~2022-04-16 2:08 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 [this message]
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
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=YloVFn0SC/SF33b3@nand.local \
--to=me@ttaylorr.com \
--cc=chooglen@google.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=justin@justinsteven.com \
--cc=martinvonz@google.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.