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

A migration from a git:// address is now refused, and every remote fetch speaks only https:http. The migrate suites pass (25 tests). I couldn't run bun x tsc --noEmit because bun can't write to its tempdir in this sandbox, so the type check is unverified.

What changed

• migrateUrl in src/actions/migrate.ts no longer lets git: through. It returns undefined, because safeRemoteUrl already rejects any scheme other than https and http.
• The invalid_url message, shown on the migrate page and in the API's 422, now says: "A git:// address is not supported: use its https:// address."
• I removed the ALLOWED_PROTOCOL = "https:http:git" constant. Both migration fetches now use the default REMOTE_PROTOCOLS, as the mirror fetch already did.
• In test/migrate.test.ts, the old assertion that git:// passes through now asserts it is refused. It also asserts that an https:// address is still accepted and that the message names git://.
• The new test/migrate-git-protocol.test.ts asserts that the default protocol list is https:http and that remoteGitEnv sets it. It also scans src/ for the old three-protocol string, a hard-coded GIT_ALLOW_PROTOCOL, and a caller passing its own protocol list. A source scan is cruder than an assertion on the environment each fetch runs with.

Left out

• I added no separate error code for git://, and I didn't touch the TUI's generic "that URL is not valid" line. A distinct code would be wider than this issue needs.
• A migration already in flight from git:// is not cancelled. Its fetch will now fail at git's protocol check, which the issue allows ("finish or fail").

Try it Run bun test test/migrate. In the migrate form, paste git://example.com/a/b.git. It should be refused with the new wording, and the https:// form of the same address should still go through.

🤖 Generated with Claude Code

Closes #3613

A migration from a git:// address is now refused, and every remote fetch speaks only https:http. The migrate suites pass (25 tests). I couldn't run bun x tsc --noEmit because bun can't write to its tempdir in this sandbox, so the type check is unverified.

What changed

• migrateUrl in src/actions/migrate.ts no longer lets git: through. It returns undefined, because safeRemoteUrl already rejects any scheme other than https and http.
• The invalid_url message, shown on the migrate page and in the API's 422, now says: "A git:// address is not supported: use its https:// address."
• I removed the ALLOWED_PROTOCOL = "https:http:git" constant. Both migration fetches now use the default REMOTE_PROTOCOLS, as the mirror fetch already did.
• In test/migrate.test.ts, the old assertion that git:// passes through now asserts it is refused. It also asserts that an https:// address is still accepted and that the message names git://.
• The new test/migrate-git-protocol.test.ts asserts that the default protocol list is https:http and that remoteGitEnv sets it. It also scans src/ for the old three-protocol string, a hard-coded GIT_ALLOW_PROTOCOL, and a caller passing its own protocol list. A source scan is cruder than an assertion on the environment each fetch runs with.

Left out

• I added no separate error code for git://, and I didn't touch the TUI's generic "that URL is not valid" line. A distinct code would be wider than this issue needs.
• A migration already in flight from git:// is not cancelled. Its fetch will now fail at git's protocol check, which the issue allows ("finish or fail").

Try it Run bun test test/migrate. In the migrate form, paste git://example.com/a/b.git. It should be refused with the new wording, and the https:// form of the same address should still go through.

🤖 Generated with Claude Code

Both migration fetches are now pinned to the address the forge vetted, and a git:// migration is refused. The migrate tests pass (25). I could not run the type check: bun install and bun x tsc both fail here with "unable to write files to tempdir", and TypeScript isn't installed. The forge's check will be the first type check.

Changes

• resolveSource in src/actions/migrate.ts now builds a pin from the vetted address with pinFor(url, vetted.value[0]) and keeps it on Resolved.pin. A small fetchEnv(source, authEnv) passes it to remoteGitEnv, and both cloneInto and fetchForkHeads use it.
• When the caller may reach private hosts (admin, trusted host, or FORGE_MIGRATE_PRIVATE_HOSTS), nothing is vetted and nothing is pinned.
• A public-looking name that fails to resolve is now refused as unreachable. Before, it went on to git unpinned, which left the rebinding window open.
• test/migrate.test.ts has a new test. It checks that the env a vetted fetch runs with contains http.curloptResolve set to looks-public.example:443:93.184.216.34. It also checks that an unresolvable name is refused and that the unvetted path carries no pin.
• The source-scan test is gone. test/migrate-git-protocol.test.ts now asserts on behaviour only: REMOTE_PROTOCOLS is https:http, and remoteGitEnv and fetchEnv set GIT_ALLOW_PROTOCOL to it.
• The TUI's invalid_url line in src/tui/screens/common.ts now says a git:// address is not supported and to use its https:// address. It is a shared error table, so the added wording shows wherever invalid_url appears there.

Not done: a migration already in flight from git:// is not cancelled. Its fetch fails at the protocol check.

Try it: run bun test test/migrate. Pasting git://example.com/a/b.git into the migrate form is refused with the new wording.

🤖 Generated with Claude Code