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

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

[Danoloan]

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

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

[Junio C Hamano]

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.

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

[Danoloan]

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ó:
> 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.