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

From: Danoloan <danolo@danoloan.es>
Date: Jun 5, 2024, 21:03 UTC
Message-ID: <9cfa7220a143046eb792c7361ea371c29e65eb18.camel@danoloan.es>
In-Reply-To: <xmqqtti7s3at.fsf@gitster.g>

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

Show 19 quoted lines

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