From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 99FBE1F4D7 for ; Mon, 2 May 2022 14:06:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236739AbiEBOJk (ORCPT ); Mon, 2 May 2022 10:09:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237107AbiEBOJP (ORCPT ); Mon, 2 May 2022 10:09:15 -0400 Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAA9A11C0A for ; Mon, 2 May 2022 07:05:37 -0700 (PDT) Received: from host-84-13-159-41.opaltelecom.net ([84.13.159.41] helo=[192.168.1.37]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1nlWgB-00075X-BW; Mon, 02 May 2022 15:05:35 +0100 Message-ID: <324301af-4ad3-739c-25bb-1ddbe069eb3e@iee.email> Date: Mon, 2 May 2022 15:05:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Bare repositories in the working tree are a security risk Content-Language: en-GB To: Glen Choo , Taylor Blau Cc: git@vger.kernel.org, Emily Shaffer , justin@justinsteven.com, Johannes Schindelin , =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= , Derrick Stolee , Junio C Hamano , "brian m. carlson" , rsbecker@nexbridge.com References: From: Philip Oakley In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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