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

`forge sync` gives git the token only for an https (or loopback) remote on the workbench's own host #7400

shipped production is serving it opened this has it
opened this

Follow-up from the review of #7397 (#7377). loadConfig now refuses plain http to another machine for API calls, but forge sync hands the token to git through tokenGitEnv (http.extraHeader: Authorization: Bearer …) for two URLs nothing checks: pin.cloneUrl as the server returns it (src/cli/sync.ts remoteFor) on a clone, and on a fetch, whatever origin URL the existing clone under the root has (git.remoteUrl(dir), src/cli/sync.ts visit). An origin that someone edited to http://other-host/... gets the token in clear, and so does any other host.

Done:

  • [ ] visit passes the token env only when the clone or fetch URL has the workbench's own origin (scheme + host + port) and passes plainHttpRemote (or is the stored --insecure workbench). Otherwise git runs without the token, and the report says why in one line.
  • [ ] A test in test/cli-sync.test.ts proves an existing clone whose origin is http://other.example/... is fetched without the token env, and a clone on the workbench's own https origin still gets it.

Files: src/cli/sync.ts, test/cli-sync.test.ts.

commented

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs