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

Re: Git submodule recursive update not syncing submodule URLs makes the operation fail for commits updating the URLs

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 5, 2024, 17:32 UTC
Message-ID
<xmqqtti7s3at.fsf@gitster.g>
In-Reply-To
<7869f213fe59fa80b9e8331dde89e795bd8cd5d4.camel@danoloan.es>
Danoloan <danolo@danoloan.es> writes:
> the old one. This is typical when the new URL may be a fork or a mirror
> in another server.

Isn't the flip side of the same coin that you can sneak in a change to .gitmodules in the superproject ("hey I have this neat fork of the superproject at this other URL, please pull from me"), so that it points at a malicious URL? If the end-user is not given a chance to inspect where the URL moved to and agree (or disagree) to switch to that other URL, your "recursive" update will end up fetching from an unverified URL into the submodule without anybody watching, no?

So, I suspect that it is working as a security measure that it does not blindly sync.

Yes "git clone --recursive" may be looser, but I would actually consider use of "--recursive" there as a security lapse.

Previous: DanoloanNext: Danoloan
Message 2 of 3 in “Git submodule recursive update not syncing submodule URLs makes the operation fail for commits updating the URLs”
  1. DanoloanJun 5, 2024
  2. Junio C HamanoJun 5, 2024
  3. DanoloanJun 5, 2024

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.