Re: [BUG] fatal: transport 'file' not allowed during submodule add

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Dec 28, 2022, 22:10 UTC
Message-ID: <Y6y+zkUsPhknTYH/@google.com>
In-Reply-To: <011201d91aca$a5db7800$f1926800$@nexbridge.com>

Hi Randall,

rsbecker@nexbridge.com wrote:

> Junio C Hamano wrote:

Show 6 quoted lines

>> This suspiciously sounds like what a1d4f67c (transport: make `protocol.file.allow`
>> be "user" by default, 2022-07-29) is doing deliberately.
>
> I have tried using 'git config --local protocol.file.allow always' and/or
> 'git config --local protocol.allow always' to get past this, without
> success.

Does `git config --global protocol.file.allow always` do the trick?

>>                                                           Taylor, does this look like a
>> corner case the 2.30.6 updates forgot to consider?

I think it's the intended effect (preventing file:// submodules), but I wonder if this hints that we'd want that protection to be more targeted. A file:// submodule (as opposed to a bare path without URL scheme) wouldn't trigger the "git clone --local" behavior that that commit mentions wanting to protect against, so at first glance it would appear to be no more or less dangerous than cloning from a remote repository.

One thing I'd be curious about is whether --local happening automatically is actually worth it nowadays. "git worktree" does a better job of sharing with an existing local repository, since the sharing continues even after the worktree has been created, after any "git gc" operations, and so on. Meanwhile, the distinction between file:// and bare paths is subtle enough that I regularly encounter people not being aware of it (for example when wanting a way to test protocol code locally and not understanding why a bare-path clone doesn't do that). Would it be more in the spirit of secure defaults to require --local when someone wants to request the hardlinking trick of local clone?

Thanks, Jonathan