git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philip Oakley <philipoakley@iee.email>
To: Glen Choo <chooglen@google.com>, Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, "Emily Shaffer" <emilyshaffer@google.com>,
	justin@justinsteven.com,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Derrick Stolee" <derrickstolee@github.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	rsbecker@nexbridge.com
Subject: Re: Bare repositories in the working tree are a security risk
Date: Mon, 2 May 2022 15:05:33 +0100	[thread overview]
Message-ID: <324301af-4ad3-739c-25bb-1ddbe069eb3e@iee.email> (raw)
In-Reply-To: <kl6ly1zno328.fsf@chooglen-macbookpro.roam.corp.google.com>

On 30/04/2022 00:57, Glen Choo wrote:
> If I were designing Git from scratch, I would probably block embedded bare repos
> from being committed altogether - if an embedded bare repo doesn't behave
> particularly differently from `.git` (which we pretty much agree we should not
> support), then this is just an inherently dangerous way to work.
>
> But yes, we have historically allowed embedded bare repos, and I don't think we
> should stop supporting them altogether. For instance, I don't see a good
> alternative for the test fixture use case:
>
> - Submodules aren't a good fit because they only allow you to include the
>   contents of a submodule's tree, whereas in a test fixture, you really do want
>   the gitdir internals to be source controlled so that you get nice predictable
>   results.
> - Users could store the repos in some other form e.g. CDN, tarball. It's fine
>   when running from a test script, but it's pretty awful to author/review any
>   changes.

Can I check that storing bundles (of other repos) within a repository is
considered reasonably safe?

I have been looking at how Git's documentation could carry with it small
exemplar repositories that cover the commit hierarchies shown in the
various man pages to allow users to see, explore and understand the man
page examples. I'd settled on bundles as a reasonable compromise, with
the exemplar repositories being generated via the test suite
(obviously). With the recent focus on security issues, I thought it
worth asking now.

> - Perhaps the users could munge the bare repo at commit time e.g. instead of
>   storing (refs/, objects/, HEAD), they could store (test_refs/, test_objects/,
>   test_HEAD), which would later get turned into the bare repo in the test
>   script. It's a little silly, but not unreasonable for a test script, I think.
--
Philip

  parent reply	other threads:[~2022-05-02 14:06 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
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 [this message]
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=324301af-4ad3-739c-25bb-1ddbe069eb3e@iee.email \
    --to=philipoakley@iee.email \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=chooglen@google.com \
    --cc=derrickstolee@github.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=justin@justinsteven.com \
    --cc=me@ttaylorr.com \
    --cc=rsbecker@nexbridge.com \
    --cc=sandals@crustytoothpaste.net \
    --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).