{"thread":{"id":"61591","subject":"Git submodule recursive update not syncing submodule URLs makes the operation fail for commits updating the URLs","startedAt":"2024-06-05T14:48:03Z","lastAt":"2024-06-05T21:04:00Z","messageCount":3,"participants":["Danoloan","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"496371","messageId":"7869f213fe59fa80b9e8331dde89e795bd8cd5d4.camel@danoloan.es","threadId":"61591","inReplyTo":null,"subject":"Git submodule recursive update not syncing submodule URLs makes the operation fail for commits updating the URLs","fromName":"Danoloan","fromEmail":"danolo@danoloan.es","sentAt":"2024-06-05T14:02:10Z","receivedAt":"2024-06-05T14:48:03Z","isPatch":false,"sender":{"key":"danolo@danoloan.es","avatar":null},"body":"Hello all,\n\nI've noticed that changing the URL of a submodule may break the\nusefulness of git submodule update --recursive. For example, take a\ncommit A1 in the repo A that has a submodule B with the commit B1. In\ncommit A2, the URL of the submodule B is updated, and the commit is\nupdated too to commit B2. B2 is present in the new URL of B but not in\nthe old one. This is typical when the new URL may be a fork or a mirror\nin another server.\n\nGiven this scenario, the following steps will fail:\n  - Clone A\n  - Check out A1\n  - Init submodules and recursively update\n  - Check out A2\n  - git submodule update --recursive --force will fail\n\nThis is because B2 is not present in the URL of B configured in the\n.gitmodules file of A2.\n\nDo you think this use case should be fixed? I'm thinking that the\n\"sync\" operation should be implied in the git submodule update. It can\nbe the default behaviour or a new option \"--sync\" could be added.\n\nThanks in advance for your attention & BR\n\n\n"},{"id":"496387","messageId":"xmqqtti7s3at.fsf@gitster.g","threadId":"61591","inReplyTo":"7869f213fe59fa80b9e8331dde89e795bd8cd5d4.camel@danoloan.es","subject":"Re: Git submodule recursive update not syncing submodule URLs makes the operation fail for commits updating the URLs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-05T17:32:58Z","receivedAt":"2024-06-05T17:33:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Danoloan <danolo@danoloan.es> writes:\n\n> the old one. This is typical when the new URL may be a fork or a mirror\n> in another server.\n\nIsn't the flip side of the same coin that you can sneak in a change\nto .gitmodules in the superproject (\"hey I have this neat fork of\nthe superproject at this other URL, please pull from me\"), so that\nit points at a malicious URL?  If the end-user is not given a chance\nto inspect where the URL moved to and agree (or disagree) to switch\nto that other URL, your \"recursive\" update will end up fetching from\nan unverified URL into the submodule without anybody watching, no?\n\nSo, I suspect that it is working as a security measure that it does\nnot blindly sync.\n\nYes \"git clone --recursive\" may be looser, but I would actually\nconsider use of \"--recursive\" there as a security lapse.\n"},{"id":"496397","messageId":"9cfa7220a143046eb792c7361ea371c29e65eb18.camel@danoloan.es","threadId":"61591","inReplyTo":"xmqqtti7s3at.fsf@gitster.g","subject":"Re: Git submodule recursive update not syncing submodule URLs makes the operation fail for commits updating the URLs","fromName":"Danoloan","fromEmail":"danolo@danoloan.es","sentAt":"2024-06-05T21:03:39Z","receivedAt":"2024-06-05T21:04:00Z","isPatch":false,"sender":{"key":"danolo@danoloan.es","avatar":null},"body":"Thanks for the response. To be honest, I didn't even think of that\npossibility, so thanks for the clarification.\n\nThe main problem with the current implementation is that there is no\nway of doing a recursive update in this scenario even when servers may\nbe trusted. So the end-user may be able to investigate the failure,\neventually discover the root cause being the URL change, then choose\nwhether to sync and re-run the update. But thus the \"--recursive\"\nfunctionality remains broken.\n\nCould trusted servers be configured in some other way instead? Maybe in\nthe gitconfig, similar to how the file:// protocol may be (un)allowed?\nOr something similar to SSH's known_hosts? Of course, that would only\nmake sense if the \"--recursive\" functionality is meant to be supported\nin this case.\n\nThanks & BR\n\n\nEl mié, 05-06-2024 a las 10:32 -0700, Junio C Hamano escribió:\n> Danoloan <danolo@danoloan.es> writes:\n> \n> > the old one. This is typical when the new URL may be a fork or a\n> > mirror\n> > in another server.\n> \n> Isn't the flip side of the same coin that you can sneak in a change\n> to .gitmodules in the superproject (\"hey I have this neat fork of\n> the superproject at this other URL, please pull from me\"), so that\n> it points at a malicious URL?  If the end-user is not given a chance\n> to inspect where the URL moved to and agree (or disagree) to switch\n> to that other URL, your \"recursive\" update will end up fetching from\n> an unverified URL into the submodule without anybody watching, no?\n> \n> So, I suspect that it is working as a security measure that it does\n> not blindly sync.\n> \n> Yes \"git clone --recursive\" may be looser, but I would actually\n> consider use of \"--recursive\" there as a security lapse.\n\n"}]}