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

Hello all,

I've noticed that changing the URL of a submodule may break the usefulness of git submodule update --recursive. For example, take a commit A1 in the repo A that has a submodule B with the commit B1. In commit A2, the URL of the submodule B is updated, and the commit is updated too to commit B2. B2 is present in the new URL of B but not in the old one. This is typical when the new URL may be a fork or a mirror in another server.

Given this scenario, the following steps will fail:
  - Clone A
  - Check out A1
  - Init submodules and recursively update
  - Check out A2
  - git submodule update --recursive --force will fail

This is because B2 is not present in the URL of B configured in the .gitmodules file of A2.

Do you think this use case should be fixed? I'm thinking that the "sync" operation should be implied in the git submodule update. It can be the default behaviour or a new option "--sync" could be added.

Thanks in advance for your attention & BR

Danoloan <danolo@danoloan.es> writes:

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.

Thanks for the response. To be honest, I didn't even think of that possibility, so thanks for the clarification.

The main problem with the current implementation is that there is no way of doing a recursive update in this scenario even when servers may be trusted. So the end-user may be able to investigate the failure, eventually discover the root cause being the URL change, then choose whether to sync and re-run the update. But thus the "--recursive" functionality remains broken.

Could trusted servers be configured in some other way instead? Maybe in the gitconfig, similar to how the file:// protocol may be (un)allowed? Or something similar to SSH's known_hosts? Of course, that would only make sense if the "--recursive" functionality is meant to be supported in this case.

Thanks & BR

El mié, 05-06-2024 a las 10:32 -0700, Junio C Hamano escribió: