unable to fetch flake submodule (unexpected authority) using SSH transport

[tones111]

Describe the bug

I'm trying to add a submodule to my NixOS flake repository to segregate secrects, but attempting to nix flake update or nixos-rebuild build results in an unexpected error:

$ sudo nixos-rebuild build
building the system configuration...
warning: could not read HEAD ref from repo at '/home/paul/src/nix-config', using 'master'
error:
       … while fetching the input 'git+file:///home/paul/src/nix-config?rev=de26939a1ff68c8e38542163e0c9d17555e17f4f&submodules=1'

       error: file:// URL 'file://moserv.lan.home.arpa:/storage/src/nix-secrets.git' has unexpected authority 'moserv.lan.home.arpa'

Steps To Reproduce

1. Add a submodule to your flake repository: git submodule init && git submodule add some_server:/path/to/repo.git secrets
2. Update flake.nix to declare submodule use: inputs.self.submodules = true;
3. Attempt to build sudo nixos-rebuild build
4. Observe "has unexpected authority error"

Expected behavior

flake builds successfully

Metadata

$ nix-env --version
nix-env (Nix) 2.31.2+1

Additional context

The error is similar to #7545 #14244, but I think this is likely a different edge case.

The error didn't occur immediately. It was only once the changes to my NixOS configuration started stabilizing that the failure started happening every time. Also, it appears to work better when the username is specified in the submodule url (user@host:/path/to/reo.git), however, that prevents other users from being able to work on the repository.

Checklist

• checked latest Nix manual (source)
• checked open bug issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.

[tones111]

I'm very new to nix/NixOS, but I believe I've located a couple relevant tests.

In the case where an SCP-like URL provides a username it gets parsed into an ssh scheme (as expected).

        // SCP-like URL (rewritten to ssh://)
        FixGitURLParam{
            .input = "git@github.com:owner/repo.git",
            .expected = "ssh://git@github.com/owner/repo.git",
            .parsed =
                ParsedURL{
                    .scheme = "ssh",
                    .authority =
                        ParsedURL::Authority{
                            .host = "github.com",
                            .user = "git",
                        },
                    .path = {"", "owner", "repo.git"},
                },
        },

However, when an SCP-like URL doesn't include the username (my problematic case) it gets parsed into a file scheme.

    // Cannot "to_string" this because has illegal path not starting
    // with `/`.
    EXPECT_EQ(
        fixGitURL("github.com:owner/repo.git"),
        (ParsedURL{
            .scheme = "file",
            .authority = ParsedURL::Authority{},
            .path = {"github.com:owner", "repo.git"},
        }));

A url.cc comment suggests this URI is invalid due to the relative path.

    if (authority.has_value()) {
        /* If a URI contains an authority component, then the path component
           must either be empty or begin with a slash ("/") character. */
        assert(path.empty() || path.front().empty());

However, the url in my .gitmodules file specifies an absolute path, so I think it should parse into an ssh scheme.

$ cat .gitmodules
[submodule "secrets"]
	path = secrets
	url = moserv.lan.home.arpa:/storage/src/nix-secrets.git

[xokdvium]

Yeah, fitGitUrl is the culprit. There's an old issue about it that I can't seem to find right now.

[xokdvium]

Those tests are there because we haven't gotten around to fixing that issue and instead added tests for broken cases. As you can see, there are quite a few of them.

[tones111]

Yeah, I just discovered the SCP regex in fixGitURL needs an @ to match, so it only knows how to parse user@host style urls.

ParsedURL fixGitURL(std::string url)
{
    std::regex scpRegex("([^/]*)@(.*):(.*)");
    if (!hasPrefix(url, "/") && std::regex_match(url, scpRegex))
        url = std::regex_replace(url, scpRegex, "ssh://$1@$2/$3");

[tones111]

Spent some time investigating and fixGitURL is pretty cursed. I believe it's responsible for trying to normalize a bunch of disparate conventions into something boost is able to parse as a URI.

I'm confused by the IPv6 test. Why are the first two parsed path elements empty? The expected string also doesn't look right as I'd expect only one / before "home".