[nodo]

Problem

When bootstrapping from a github.com source without --target-max-pack-bytes, git-sync asks the GitHub REST API (GET /repos/{owner}/{repo}) for the repository size. It switches to 512 MiB batches when the size is 1.5 GiB or more. That lookup sent no credentials. For a private repository GitHub answers 404 to an anonymous caller, so every private repository bootstrapped as a single pack, whatever its size.

Nothing reported this:

• Every failure (non-200, transport error, parse error) returned silently.
• The "selected batched mode" message only showed with verbose logging.

Public repositories were exposed too: anonymous calls share GitHub's 60 requests/hour limit per egress IP.

Changes

Authenticated lookup

• The size request now carries the source connection's credentials (basic or bearer): an explicit token, a user:token@ in the source URL, or credentials the git credential helper supplied when the git server asked for them. A public repository never asks, so with only a helper its lookup stays anonymous. A URL username without a password is not sent: it may be an account name.
• If the API refuses the token with 401 or 403 (for example an SSO-unauthorized PAT), the lookup retries once anonymously. A public repository is never worse off than before. If the retry fails too, the refusal is reported rather than hidden behind the retry's 404.
• The new HTTPConn.CredentialsFor(dest) decides which credentials may go to the API, checking the real destination. Each credential is measured from the URL it is bound to (the endpoint for explicit and URL credentials, the looked-up host for helper ones), the destination must be same-site with it, and with TLS verification off nothing crosses to another host. So helper credentials looked up for a redirect host stay with that host, and an API base on another site gets nothing.
• GitHubOwnerRepo now treats github.com as GitHub only on its scheme's default port. The connection's redirect guard still strips credentials from any hop that leaves the API's site, and the logged authenticated reflects the request that actually produced the answer.

Visible outcome

• Every lookup that is attempted is logged through Options.BootstrapLogger. This does not need verbose mode.
• Fields: repository, authenticated, http_status, refused_auth_status, refused_auth_error, size_kb or error, threshold_kb, mode, target_max_pack_bytes.
• A failed lookup logs at WARN and also prints a notice that the bootstrap starts with a single pack, so CLI users see it without -v (it can still switch to batches if the target rejects the pack). The notice names the token refusal when there was one. Under -v the failure is printed once, and the verbose log and BootstrapLogger use the same record name.

Hardening

• A reported size of 0 counts as unknown, like a missing or negative size: bootstrap only runs with source refs, so 0 means GitHub has not sized the repo yet. It warns and prints the notice.
• A cancelled run reports nothing. Every error text (transport errors included) is cleaned before it is logged or printed.
• A 401/403 counts as a refused token only when the request still carried it, so a redirect that stripped the credentials is neither retried nor blamed on the token.
• Wiki sources (owner/repo.wiki) get no lookup: the API has nothing to size.
• Each lookup request has its own 30s timeout, so a slow refusal does not starve the anonymous retry.
• GitHub's error message is cleaned (control characters including C1, bidi formatting) and truncated before it is logged.

Docs

• docs/usage.md documents the lookup and its credential scope.
• Updated the BootstrapLogger doc comments and CHANGELOG.md.

Tests

New file internal/strategy/bootstrap/github_preflight_test.go, written test-first. It covers:

• a private repo: 404 without auth, 200 with auth, so batched (also end-to-end through Execute);
• a bearer token, user:token@ URL credentials, and a bare URL username not being sent;
• no credentials with TLS verification off, or to an API base on another site;
• lookup failure: one-shot, a WARN record and a notice;
• the anonymous retry on 401/403, the refusal reported when the retry fails too, and no retry on other failures;
• a transport error, and unusable bodies (not JSON, no size, negative size);
• sanitizing GitHub's error message;
• a small repo staying one-shot without a warning, and one reporting size 0 warning as unknown;
• a cancelled run, unclean transport errors, an unauthenticated 403 after a redirect, and the per-attempt timeout;
• skipped lookups (caller already batching, non-default port, non-GitHub host);
• a redirect that leaves the API's site dropping credentials (asserting the target was reached, and logged as unauthenticated);
• CredentialsFor in internal/gitproto/smarthttp_test.go: explicit, helper and URL credentials, helper credentials bound to a redirect host, and TLS verification off.

The preflight tests reach a local TLS server as https://api.github.com, so the destination check runs as in production.

The new tests fail against the previous implementation. go test ./..., go test -race on the affected packages and golangci-lint run (v2.11.4) all pass.

---

Generated by Claude Code

---

Note

Medium Risk
Touches credential scoping for cross-host API calls and bootstrap batching decisions; mistakes could leak tokens or mis-size packs, but changes are heavily tested and fail closed on redirects/TLS-off.

Overview
Fixes batched bootstrap for large private GitHub repos by sending source credentials on the GET /repos/{owner}/{repo} size preflight (scoped to api.github.com via new HTTPConn.CredentialsFor), with same-site/TLS rules aligned to redirect handling and helper creds bound to authOrigin.

The preflight moves into github_preflight.go with structured BootstrapLogger / PushLogger records, CLI notices on lookup failure, 401/403 → one anonymous retry, stricter GitHubOwnerRepo parsing, and sanitize.Line for API/error text in logs. Docs and changelog describe the behavior.

^{Reviewed by Cursor Bugbot for commit d0e7b78. Configure here.}

[cursor]

Stale Bugbot comment from a previous run.

[Copilot]

🟡 Changes recommended

Credential reuse can cross service boundaries, and URL-embedded credentials remain unsupported by the preflight.

2 open issues

• Redirected helper credentials reused across hosts · New
• URL userinfo credentials omitted from API lookup · New

What changed in this PR

Updates GitHub’s repository-size preflight to support authenticated lookups and make bootstrap mode selection visible.

Changes:

• Adds authenticated requests with anonymous fallback on 401/403.
• Adds outcome logging, failure notices, timeout and response safeguards.
• Adds regression tests and updates documentation.

File	Description
unstable/​client.go	Documents size-lookup diagnostics.
internal/​strategy/​bootstrap/​github_preflight_test.go	Tests authentication, fallback, logging and batching.
internal/​strategy/​bootstrap/​bootstrap.go	Implements authenticated preflight and outcome reporting.
docs/​usage.md	Explains lookup behavior and credential scope.
client.go	Updates logger documentation.
CHANGELOG.md	Records the preflight changes.

_{Review effort: Balanced}

[nodo]

govulncheck is red because of new Go standard-library advisories against the pinned go1.26.6 toolchain, not because of this change.

• main fails the same scan: the scheduled run on 013012a, run 39212330542.
• The fix already exists in Preserve concurrent updates and recognize already-current refs #123: 8484a5f, "Update Go to 1.27.2 for standard-library security fixes", which also bumps golangci-lint to v2.15.0.

That bump isn't carried in this PR yet. It changes the shared toolchain and lint pins, so I'm waiting on a decision: port it here, or let this PR go green once #123 lands and main is merged in. A re-run would fail identically, so I haven't triggered one.

---

Generated by Claude Code

[nodo]

Ported the Go 1.27.2 bump from #123 as 58e81ac (cherry-pick of 8484a5f). It no-ops once #123 lands. Verified locally on go1.27.2:

• govulncheck reports 0 vulnerabilities in called code;
• go test ./... passes;
• golangci-lint v2.15.0 reports 0 issues.

---

Generated by Claude Code

[nodo]

Update: the Go 1.27.2 port (58e81ac) is no longer on this branch. 6e75338 was pushed on top of 068547f, so go.mod is back on go1.26.6 and govulncheck fails again for the same standard-library advisories as main.

58e81ac itself passed every check, govulncheck included. The fix is still #123's toolchain bump: either re-apply it here or merge main in once #123 lands.

---

Generated by Claude Code

[nodo]

bugbot run

[Copilot]

🔵 Needs a closer look

Cross-service credential reuse and redirect-sensitive authentication warrant final human security review.

No open issues 🎉

2 resolved since last review

• Redirected helper credentials reused across hosts
• URL userinfo credentials omitted from API lookup

_{Review effort: Balanced}

[cursor]

Stale Bugbot comment from a previous run.

[pjbgf]

One low-severity finding from a git-conformance, security and performance review. The rest of the credential scoping (redirect binding, helper origin, TLS-off, log sanitisation) checked out.

---

Generated by Claude Code

[nodo]

bugbot run

[Copilot]

🟡 Changes recommended

Custom transports with missing response provenance can incorrectly suppress the anonymous retry after token refusal.

1 open issue

• Preserve authentication when Response.Request is nil · New

_{Review effort: Balanced}

[cursor]

Stale Bugbot comment from a previous run.

[nodo]

bugbot run

[Copilot]

🟢 Approval recommended

Credential scoping, retry behavior, and diagnostics have targeted regression coverage, with no unresolved blocking findings.

No open issues 🎉

1 resolved since last review

• Preserve authentication when Response.Request is nil

_{Review effort: Balanced}

[cursor]

Stale Bugbot comment from a previous run.

[nodo]

bugbot run

[Copilot]

🟢 Approval recommended

No unresolved blocking issues remain, and targeted regression coverage addresses credential scoping, retries, diagnostics, and batching selection.

No open issues 🎉

_{Review effort: Balanced}

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit d0e7b78. Configure here.}

[nodo]

govulncheck is red on d0e7b78 because of a newly published standard-library advisory, GO-2026-6809: crypto/x509 should distrust compromised intermediate certificates. This PR's code doesn't cause it. The advisory affects go1.27.2, which main also pins, and is fixed in go1.27.3. main's last scan predates the advisory, so main will fail the next one too. Re-running the check would fail the same way, so I haven't.

No fix PR exists yet. Verified locally:

• go1.27.2: GO-2026-6809 reported;
• go1.27.3: govulncheck reports 0 vulnerabilities in called code, go test ./... passes, and golangci-lint v2.15.0 reports 0 issues.

Proposed patch:

--- a/go.mod
+++ b/go.mod
-toolchain go1.27.2
+toolchain go1.27.3
--- a/mise.toml
+++ b/mise.toml
-go = { version = '1.27.2', ...
+go = { version = '1.27.3', ...

This can land on its own against main (preferable) or ride along here.

---

Generated by Claude Code