git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date
Dec 30, 2022, 21:43 UTC
Message-ID
<000701d91c97$cc35fd30$64a1f790$@nexbridge.com>
In-Reply-To
<Y69SRs9ifDPagOUo@nand.local>
On December 30, 2022 4:04 PM, Taylor Blau wrote:
Show 46 quoted lines
>On Wed, Dec 28, 2022 at 09:42:39AM -0500, rsbecker@nexbridge.com wrote:
>> >-----Original Message-----
>> >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.
I have reproduced this on multiple platforms including NonStop and Cygwin64 on Windows with the same results as earlier. The protocol.file.allowed=always does not appear to even get considered. With some fprintfs in the code, the code in is_transport_allowed falls through to the PROTOCOL_ALLOW_USER_ONLY case and only considers environment variable GIT_PROTOCOL_FROM_USER, which is not passed into the child doing the submodule add. The is_transport_allowed("file",-1) always returns 0 no matter what and 0 is what gets used upwards. There is no difference in the behaviour regardless of the protocol.file.allowed value either in -c, .gitconfig, or on the user environment variable.
Previous: Taylor BlauNext: rsbecker@nexbridge.com
Message 10 of 12 in “[BUG] fatal: transport 'file' not allowed during submodule add”
  1. rsbecker@nexbridge.comDec 27, 2022
  2. Junio C HamanoDec 28, 2022
  3. rsbecker@nexbridge.comDec 28, 2022
  4. Jonathan NiederDec 28, 2022
  5. rsbecker@nexbridge.comDec 28, 2022
  6. Taylor BlauDec 30, 2022
  7. rsbecker@nexbridge.comDec 30, 2022
  8. Jeff KingJan 3, 2023
  9. Taylor BlauDec 30, 2022
  10. rsbecker@nexbridge.comDec 30, 2022
  11. rsbecker@nexbridge.comDec 30, 2022
  12. rsbecker@nexbridge.comDec 30, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.