From: Glen Choo <firstname.lastname@example.org>
Cc: Emily Shaffer <email@example.com>,
firstname.lastname@example.org, Taylor Blau <email@example.com>
Subject: Re: Bare repositories in the working tree are a security risk
Date: Fri, 15 Apr 2022 17:34:20 -0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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.
next prev parent reply other threads:[~2022-04-16 2:49 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 [this message]
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 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).