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

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Dec 28, 2022, 22:25 UTC
Message-ID: <013501d91b0b$3cd4ceb0$b67e6c10$@nexbridge.com>
In-Reply-To: <Y6y+zkUsPhknTYH/@google.com>

On December 28, 2022 5:11 PM, Jonathan Nieder wrote:

Show 7 quoted lines

>Hi Randall,
>
>rsbecker@nexbridge.com wrote:
>> Junio C Hamano wrote:
>
>>> This suspiciously sounds like what a1d4f67c (transport: make
>>> `protocol.file.allow` be "user" by default, 2022-07-29) is doing

deliberately.

Show 6 quoted lines

>>
>> 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?

I tried git config --local protocol.file.allow always after the initial clone. This should work but does not. I also tried git config --global protocol.file.allow always before the initial clone. This also did not work.

>>>                                                           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?

I think the risk of someone hacking a hardlink is less risky than someone misdirecting a remote site not under a user's direct control.

The tests I did show the same behaviour no matter which combination of the above. --local appears to be implied, at least there is no apparent behavioural difference between specifying the argument and not.

--Randall