Re: [PATCH v3] setup: trace bare repository setups
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 5, 2023, 22:30 UTC
- Message-ID
- <xmqqa5yicsxd.fsf@gitster.g>
- In-Reply-To
- <e98be8e7f703fc741e06d9208545abc8c24d1a4a.1682962110.git.steadmon@google.com>
Josh Steadmon <steadmon@google.com> writes:
Show 34 quoted lines
> From: Glen Choo <chooglen@google.com> > > safe.bareRepository=explicit is a safer default mode of operation, since > it guards against the embedded bare repository attack [1]. Most end > users don't use bare repositories directly, so they should be able to > set safe.bareRepository=explicit, with the expectation that they can > reenable bare repositories by specifying GIT_DIR or --git-dir. > > However, the user might use a tool that invokes Git on bare repositories > without setting GIT_DIR (e.g. "go mod" will clone bare repositories > [2]), so even if a user wanted to use safe.bareRepository=explicit, it > wouldn't be feasible until their tools learned to set GIT_DIR. > > To make this transition easier, add a trace message to note when we > attempt to set up a bare repository without setting GIT_DIR. This allows > users and tool developers to audit which of their tools are problematic > and report/fix the issue. When they are sufficiently confident, they > would switch over to "safe.bareRepository=explicit". > > Note that this uses trace2_data_string(), which isn't supported by the > "normal" GIT_TRACE2 target, only _EVENT or _PERF. > > [1] https://lore.kernel.org/git/kl6lsfqpygsj.fsf@chooglen-macbookpro.roam.corp.google.com/ > [2] https://go.dev/ref/mod > > Signed-off-by: Glen Choo <chooglen@google.com> > Signed-off-by: Josh Steadmon <steadmon@google.com> > --- > I'm sending a lightly-adapted version of Glen's tracing patch because > Glen will be on vacation next week and we'd like to get this upstream > ASAP. > > Changes in V3: added a test_unconfig test case for safe.bareRepository > Changes in V2: cleaned up test-style issues.
Thanks. We saw no interest on the list in reviewing this patch further, it seems, but I didn't see anything glaringly wrong, see no reason not to merge it, and this should help noticing potential issues by $corp folks, I would presume, so let's merge it as-is.