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
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.
Follow-up from the review of #7397 (#7377).
loadConfignow refuses plain http to another machine for API calls, butforge synchands the token to git throughtokenGitEnv(http.extraHeader: Authorization: Bearer …) for two URLs nothing checks:pin.cloneUrlas the server returns it (src/cli/sync.tsremoteFor) on a clone, and on a fetch, whateveroriginURL the existing clone under the root has (git.remoteUrl(dir),src/cli/sync.tsvisit). Anoriginthat someone edited tohttp://other-host/...gets the token in clear, and so does any other host.Done:
visitpasses the token env only when the clone or fetch URL has the workbench's own origin (scheme + host + port) and passesplainHttpRemote(or is the stored--insecureworkbench). Otherwise git runs without the token, and the report says why in one line.test/cli-sync.test.tsproves an existing clone whoseoriginishttp://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.