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@xxxxxxxxxxx> 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.
