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>, "Johannes Schindelin" <Johannes.Schindelin@gmx.de>, "Ævar Arnfjörð Bjarmason" <email@example.com>, "Derrick Stolee" <firstname.lastname@example.org>, "Junio C Hamano" <email@example.com>, "brian m. carlson" <firstname.lastname@example.org>, email@example.com Subject: Re: Bare repositories in the working tree are a security risk Date: Fri, 15 Apr 2022 17:41:59 -0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> (resending this because I think the original got blocked, and I messed up the CC list anyway.) Hi all! Thanks for chiming in. I'm sorry I wasn't able to participate in a timely manner, and unfortunately (once again..), I will be out of the office (returning 27 Apr, PDT) and my colleagues will be keeping tabs on the discussion in my stead (once again..). Nevertheless, I think the conversation has been pretty fruitful, so I'm optimistic about next steps. Here's my understanding of the conversation thus far - do chime in if you feel I'm off base or if I've missed something: * We all agree that something needs to be done about embedded bare repos. This is a pretty good starting point IMO, because we agree that 'do nothing' isn't a good response. * There are use cases for embedded bare repos that don't have great alternatives (e.g. libgit2 uses bare repos in its tests). Even if this workflow is frowned upon (I personally don't think we should support it), I don't think we're ready to categorically declare that Git should ban embedded bare repos altogether (e.g. the way we ban .GiT). * We want additional protection on the client besides `git fsck`; there are a few ways to do this: 1. Prevent checking out an embedded bare repo. 2. Detect if the bare repo is embedded and refuse to work with it. 3. Detect if the bare repo is embedded and do not read its config/hooks, but everything else still 'works'. 4. Don't detect bare repos. 5. Only detect bare repos that are named `.git` . (I've responded with my thoughts on each of these approaches in-thread). With that in mind, here's what I propose we do next: * Merge the `git fsck` patch  if we think that it is useful despite the potentially huge number of false positives. That patch needs some fixing; I'll make the changes when I'm back. * I'll experiment with (5), and if it seems promising, I'll propose this as an opt-in feature, with the intent of making it opt-out in the future. We'll opt-into this at Google to help figure out if this is a good default or not. * If that direction turns out not to be promising, I'll pursue (1), since that is the only option that can be configured per-repo, which should hopefully minimize the fallout. Given that this embedded bare repo problem has been known for a long time, I don't think we need to rush out a fix, but (especially since I'll be OOO) I'm more than happy for someone to take my ideas (or any ideas) and run with them.  https://firstname.lastname@example.org/  https://email@example.com
next prev parent reply other threads:[~2022-04-16 2:05 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 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 [this message] 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 \ --cc=Johannes.Schindelin@gmx.de \ --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 \ --firstname.lastname@example.org \ --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).