Skip to content

[BUG] GitLab sparse-fetch rewrites ssh:// URL with custom port to HTTPS on same host #2929

Description

@fm-knopfler

Describe the bug

When a type: gitlab dependency uses an ssh:// URL with a non-standard port (e.g. ssh://git@gitlab-ssh.example.com:2222/...), the git sparse-fetch path constructs a remote URL using HTTPS against the same hostname. For GitLab instances where the SSH host alias differs from the web endpoint, this causes the git transport to speak TLS to an SSH-only host, then silently fall back to the GitLab REST API (which also fails because it reuses the SSH port with HTTPS).

To Reproduce

  1. Host: self-hosted GitLab at gitlab.example.com:443 (HTTPS web) with SSH-only alias at gitlab-ssh.example.com:2222
  2. apm.yml:
    dependencies:
      apm:
        - git: ssh://git@gitlab-ssh.example.com:2222/owner/repo.git
          path: agents/some-agent.agent.md
          type: gitlab
  3. Run apm install

Observed result

HTTPSConnectionPool(host='gitlab-ssh.example.com', port=2222):
Max retries exceeded with url: /api/v4/projects/owner%2Frepo/repository/files/...
(Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number')))

With APM_DEBUG=1:

[DEBUG] git sparse fetch: host=gitlab-ssh.example.com repo=owner/repo ref=main paths=1
[DEBUG] git transport unavailable for gitlab-ssh.example.com/owner/repo; falling back to GitLab REST API (GitFileTransportError)

strace confirms the sparse-fetch worktree used git remote add origin https://gitlab-ssh.example.com/... and invoked git-remote-https. The SSH URL and custom port were lost.

Expected behavior

The original SSH URL and port should be preserved for the git transport remote URL. A git ls-remote over the same ssh:// URL with port 2222 succeeds from the same environment.

Environment:

  • OS: Linux (container)
  • APM Version: 0.30.0
  • GitLab: self-hosted at gitlab.example.com with SSH alias gitlab-ssh.example.com:2222

Logs

strace output showing the rewritten remote URL:

execve("/usr/local/libexec/git-core/git-remote-https", [...], "origin", "https://gitlab-ssh.example.com/owner/repo.git")

Manual verification that sparse fetch works with the correct URL:

$ git -c init.defaultBranch=main init -q
$ git remote add origin ssh://git@gitlab-ssh.example.com:2222/owner/repo.git
$ git sparse-checkout init --no-cone
$ git sparse-checkout set agents/some-agent.agent.md
$ git fetch --filter=blob:none --depth=1 origin main  # succeeds
$ git checkout -q FETCH_HEAD
$ ls agents/some-agent.agent.md  # exists

Additional context

Workaround: switch the dependency to the HTTPS web URL and add a GitLab token:

- git: https://gitlab.example.com/owner/repo.git
  path: agents/some-agent.agent.md
  type: gitlab

This requires HTTPS credentials for the GitLab instance rather than SSH keys.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/lockfileLockfile schema, per-file provenance, integrity hashes, drift detection.status/in-flightA PR is open and progressing.status/triagedAutomated advice completed; deduplication only. Not human approval; silence is not approval.type/bugSomething does not work as documented.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions