[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    RE: [BUG] fatal: transport 'file' not allowed during submodule add
From:       <rsbecker () nexbridge ! com>
Date:       2022-12-30 23:16:11
Message-ID: 000201d91ca4$b868caf0$293a60d0$ () nexbridge ! com
[Download RAW message or body]

On December 30, 2022 4:04 PM, Taylor Blau wrote:
> On Wed, Dec 28, 2022 at 09:42:39AM -0500, rsbecker@nexbridge.com wrote:
> > > From: Junio C Hamano <jch2355@gmail.com> On Behalf Of Junio C Hamano
> > On December 27, 2022 10:34 PM, Junio C Hamano wrote:
> > > <rsbecker@nexbridge.com> writes:
> > > 
> > > > As of 2.39.0, I am now getting fatal: transport 'file' not allowed
> > > > when performing a submodule add after a clone -l. The simple
> > > > reproduce of this
> > > > is:
> > > > ...
> > > > This happens for any submodule add on the same system. Some online
> > > > research indicates that there was a security patch to git causing
> > > > this, but I can't find it. This does not seem correct to me or how
> > > > this
> > improves
> > > security.
> > > > Help please - this is causing some of my workflows to break.
> > > 
> > > Thanks for reporting, Randall.
> > > 
> > > This suspiciously sounds like what a1d4f67c (transport: make
> > `protocol.file.allow`
> > > be "user" by default, 2022-07-29) is doing deliberately.  Taylor,
> > > does this
> > look like a
> > > corner case the 2.30.6 updates forgot to consider?
> > 
> > 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.
> 
> I couldn't reproduce the symptom you described. Indeed, the behavior of not
> allowing local-submodules to be cloned without explicitly opting in via the
> `protocol.file.allow` configuration is intentional.
> 
> The patch Junio mentioned, a1d4f67c12 (transport: make `protocol.file.allow` be
> "user" by default, 2022-07-29) has some examples of why this behavior was
> changed in the 2.30.6 update.
> 
> If you run either `git config --global protocol.file.allow always`, or replace your \
> last submodule add with:
> 
> $ git -c protocol.file.allow=always submodule add /path/to/subsrc.git
> 
> it should work as expected.

Ok, operator error. This does work as expected if you run the test slightly \
different. If the repositories are all cloned, the upstream remotes are set up \
properly and the submodule add works. In my test case, I used git remote add with a \
relative path. This seems to be an edge condition that triggers the situation. When \
avoiding the upstream remote command (implied by clone), the submodule add works if \
the protocol.file.allow = always, no matter how it is set.

--Randall


[prev in list] [next in list] [prev in thread] [next in thread]