### Summary Since upgrade to 17.0, I see the repository check constantly failing with one specific repository: The difference to the rest of repositories is that submodules are being used. This has been working for the last approx. 3-4 years without any issues. The error being reported is: `gitmodulesUrl: disallowed submodule url` ### Steps to reproduce Unfortunately no steps possible to note here. The repo has been working flawlessly the last years and occurred after update. The most unique things: 1. Use of gitmodules 2. The projects being grouped under a group ### What is the current *bug* behavior? The repository check constantly failing in a repo where a submodule is used.  ### What is the expected *correct* behavior? No repository check error. ### Relevant logs and/or screenshots #### Error reported ``` $ cat /var/log/gitlab/gitlab-rails/repocheck.log E, [2024-06-22T21:40:23.640238 #2609557] ERROR -- : group1/dnscontrol/container: Could not fsck repository: error in blob b403dfea5fd13543b6116c5acf47ce1cc3990d1e: gitmodulesUrl: disallowed submodule url: https://gitlab.domain.tld:group1/dnscontrol/source.git E, [2024-06-22T22:18:06.933824 #2609557] ERROR -- : group1/dnscontrol/container: Could not fsck repository: error in blob b403dfea5fd13543b6116c5acf47ce1cc3990d1e: gitmodulesUrl: disallowed submodule url: https://gitlab.domain.tld:group1/dnscontrol/source.git ``` #### gitmodules First, `.gitmodules` (and in `.git`) the relative path (as recommended in various docs) is used: ``` [submodule "src"] path = src url = ../source.git branch = main ``` #### GitLab CI + Git Client Running GitLab-CI on the same repo (with using `GIT_SUBMODULE_STRATEGY: recursive`) does work just fine. It clones the submodule as expected and completes. Also, cloning the repo on a local client as well as comitting, pushing and changing the commit target of the submodule does work without any errors. The error is only specific to fsck. #### fsck I have been running `git fsck` using the `git` binary shipped with Debian 12, and it is working fine: ```text root@gitlab.domain.tld ~ $ /usr/bin/git -v git version 2.39.2 root@gitlab.domain.tld ~ $ /usr/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/d6/a4/d6a4031733610bb080d0bfa794fcc9dbdcff74834aeaab7c6b927e21e9754037.git fsck Checking object directories: 100% (256/256), done. Checking object directories: 100% (256/256), done. Checking objects: 100% (322/322), done. Verifying commits in commit graph: 100% (103/103), done. Verifying commits in commit graph: 100% (45/45), done. Verifying OID order in multi-pack-index: 100% (154/154), done. Sorting objects by packfile: 100% (155/155), done. Verifying object offsets: 100% (155/155), done. ``` However when using the `git` binary GitLab ships with, the error occurs: ```text root@gitlab.domain.tld ~ $ /opt/gitlab/embedded/bin/git -v git version 2.44.1.gl1 root@gitlab.domain.tld ~ $ /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/d6/a4/d6a4031733610bb080d0bfa794fcc9dbdcff74834aeaab7c6b927e21e9754037.git fsck Checking object directories: 100% (256/256), done. Checking object directories: 100% (256/256), done. error in blob b403dfea5fd13543b6116c5acf47ce1cc3990d1e: gitmodulesUrl: disallowed submodule url: https://gitlab.domain.tld:group1/dnscontrol/source.git Checking objects: 100% (322/322), done. Verifying commits in commit graph: 100% (103/103), done. Verifying commits in commit graph: 100% (45/45), done. Verifying OID order in multi-pack-index: 100% (154/154), done. Sorting objects by packfile: 100% (155/155), done. Verifying object offsets: 100% (155/155), done. ``` The odd part hereby being the url of the submodule: `https://gitlab.domain.tld:group1/`. I'd expect `:` only with SSH URLs, not HTTPS. I'd suspect the `git` binary being upgraded at some point, causing this issue now. ### Output of checks #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> $ sudo gitlab-rake gitlab:env:info System information System: Debian 12 Proxy: no Current User: git Using RVM: no Ruby Version: 3.1.5p253 Gem Version: 3.5.11 Bundler Version:2.5.11 Rake Version: 13.0.6 Redis Version: 7.0.15 Sidekiq Version:7.1.6 Go Version: unknown GitLab information Version: 17.1.0-ee Revision: b7514f9c21c Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 14.11 URL: https://gitlab.domain.tld HTTP Clone URL: https://gitlab.domain.tld/some-group/some-project.git SSH Clone URL: git@gitlab.domain.tld:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: saml GitLab Shell Version: 14.36.0 Repository storages: - default: unix:/var/opt/gitlab/gitaly/gitaly.socket GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Gitaly - default Address: unix:/var/opt/gitlab/gitaly/gitaly.socket - default Version: 17.1.0 - default Git Version: 2.45.1 </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> $ sudo gitlab-rake gitlab:check SANITIZE=true Checking GitLab subtasks ... Checking GitLab Shell ... GitLab Shell: ... GitLab Shell version >= 14.36.0 ? ... OK (14.36.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Internal API available: OK Redis available via internal API: OK gitlab-shell self-check successful Checking GitLab Shell ... Finished Checking Gitaly ... Gitaly: ... default ... OK Checking Gitaly ... Finished Checking Sidekiq ... Sidekiq: ... Running? ... yes Number of Sidekiq processes (cluster/worker) ... 1/1 Checking Sidekiq ... Finished Checking Incoming Email ... Incoming Email: ... Checking Reply by email ... IMAP server credentials are correct? ... Checking gitlab@domain.tld yes Mailroom enabled? ... skipped MailRoom running? ... skipped Checking Reply by email ... Finished Checking Incoming Email ... Finished Checking LDAP ... LDAP: ... LDAP is disabled in config/gitlab.yml Checking LDAP ... Finished Checking GitLab App ... Database config exists? ... yes Tables are truncated? ... skipped All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Cable config exists? ... yes Resque config exists? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units) Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units) Projects have namespace: ... 1/5 ... yes [...] 1/260 ... yes Redis version >= 6.2.14? ... yes Ruby version >= 3.0.6 ? ... yes (3.1.5) Git user has default SSH configuration? ... yes Active users: ... 8 Is authorized keys file accessible? ... skipped (authorized keys not enabled) GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes Elasticsearch version 7.x-8.x or OpenSearch version 1.x ... skipped All migrations must be finished before doing a major upgrade ... yes Checking GitLab App ... Finished Checking GitLab subtasks ... Finished </pre> </details>