From: Glen Choo <firstname.lastname@example.org> To: email@example.com Cc: Emily Shaffer <firstname.lastname@example.org>, email@example.com, Taylor Blau <firstname.lastname@example.org>, email@example.com, "brian m. carlson" <firstname.lastname@example.org> Subject: Re: Bare repositories in the working tree are a security risk Date: Wed, 13 Apr 2022 13:37:35 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Thanks for the thoughtful replies, everyone. I'm still catching up with the discussion but I thought I'd share a suggestion/observation from a colleague (cc-ed, thanks!) who was following the discussion separately. Glen Choo <email@example.com> writes: > = What can we do about it? > > Each subsection is an alternative and an analysis (+/- are pros/cons). > > == 1. Prevent users from checking out bare repos > ... > == 2. Detect and reject bare repos using `git fsck` and `transfer.fsckObjects`. > ... > == 3. Detect that we are in an embedded bare repo and ignore the embedded bare > repository in favor of the containing repo. > ... > == 4. Educate users about this risk without making code changes. Martin observed that, viability aside, there's another approach that I haven't discussed: == 5 Disable bare repo discovery We could introduce a config value that disables bare repo discovery altogether. This would only disable _discovery_; a user can still use the bare repo by specifying the gitdir (e.g. via `--git-dir=.` or GIT_DIR). + Extremely robust (for the majority of users who don't need bare repos at least). + Easy to understand. - We need to read config _before_ discovering the gitdir; although Git _can_ do this (e.g. via read_early_config()), I don't think there is precedent for doing this during repository setup. - Making this behavior opt-out would break every bare repo user (they'd need to either start passing --git-dir or change their config). - Making this behavior opt-in won't help the users who need it the most. I'm not sure if specifically "disable bare repo discovery for all users by default" is viable, but the line of thinking seems like it might yield some good ideas. Thoughts?
next prev parent reply other threads:[~2022-04-13 20:37 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-06 22:43 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 [this message] 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 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Bare repositories in the working tree are a security risk' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).