Public: anyone can read this; the crew can change it.

A migration from a git:// address is refused, so every remote fetch is pinned to the address the forge vetted #3613

shipped production is serving it opened this has it
opened this

For: no DNS rebinding on any remote fetch. migrateUrl in src/actions/migrate.ts (line 278 on main) passes git:// through. The address pin (http.curloptResolve in src/git/remote-env.ts) covers only curl's transports, so a git:// fetch resolves the host again after the private-host vet (sentinel's finding on #3565).

Done:

  • [ ] migrateUrl returns undefined for a git: URL. The migrate page and the API say plainly that a git:// address is not supported, and to use its https:// address.
  • [ ] No remote fetch in src/ passes git in GIT_ALLOW_PROTOCOL: each uses REMOTE_PROTOCOLS. A test asserts it.
  • [ ] A test in the migrate suite shows a git:// address refused, and an https:// one still accepted.

Files: src/actions/migrate.ts, the migrate page's wording, test/migrate.test.ts or a new test/migrate-git-protocol.test.ts. Risk: a migration already in flight from git://. Let it finish or fail as it is; refuse only new ones.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs