In response to CVE-2022-39253, Git now considers the file:// protocol to be unsafe by default. The default value of the protocol.file.allow config variable was changed to user^1, meaning that a file URL or a local path is only trusted if it came directly from user input, and not if it came through a command which executes a clone/fetch/push internally.
The tests fall foul of this new requirement by attempting to run a git submodule add with a local directory. Internally, this performs a clone, which is no longer trusted because of the change described above. This results in the command failing with a "transport 'file' not allowed" message.
Since this is only the case for a single command, then fix the test by setting protocol.file.allow to always when we run it.
In response to CVE-2022-39253, Git now considers the
file://protocol to be unsafe by default. The default value of theprotocol.file.allowconfig variable was changed touser^1, meaning that a file URL or a local path is only trusted if it came directly from user input, and not if it came through a command which executes a clone/fetch/push internally.The tests fall foul of this new requirement by attempting to run a
git submodule addwith a local directory. Internally, this performs a clone, which is no longer trusted because of the change described above. This results in the command failing with a "transport 'file' not allowed" message.Since this is only the case for a single command, then fix the test by setting
protocol.file.allowtoalwayswhen we run it./cc @mhagger @torstenwalter @znull