can you look at the comments on https://github.com/entireio/git-sync/pull/66 and address them?

All done. Here's the wrap-up of PR #66:

Pushed

Commit e7e4a1a is on nodo/convert-sha256.

Comments addressed (replies posted to each thread)

Verification

• go build ./..., go test ./... — clean
• Gated TestRun_GitHTTPBackend + TestRun_GitHTTPBackend_Sign (GITSYNC_E2E_SHA256_HTTP_BACKEND=1) — pass; full conversion via SetEncodedObject produces an fsck-clean SHA256 repo, and --sign-mode tips signs as before
• go test -race — clean
• golangci-lint — 0 issues
• The on-disk sha256(content) invariant test still passes against the new write path, kept as a regression guard.

One judgment call worth flagging: the refactor changes loose-object compression from zlib.BestSpeed (level 1) to go-git's default (level 6), so very large conversions will spend somewhat more CPU compressing — the trade-off you opted into by choosing the refactor. If that ever bites on kernel-scale repos, git gc on the output packs it away regardless.

Done — fix committed (ffda090) and pushed. Here's the situation:

Credential leak — fixed

The source URL can carry user:token@host, and it was being copied verbatim into three surfaces, the worst being the signed attestation tag message (permanent and pushed). Also the fetching … status line and the SourceURL field in both the text and JSON result.

Fix: a redactSourceURL helper strips the entire userinfo component before any of those surfaces. I deliberately did not use Go's url.URL.Redacted() — it only masks the password, so a token-in-username form like https://ghp_xxx@github.com/... (common for GitHub token auth) would survive untouched. The fetch path keeps the original req.SourceURL, so auth is unaffected.

Covered by a new TestRedactSourceURL (plain creds, token-as-username, x-access-token, and the unparseable-input → placeholder path). Full suite + gated E2E/signing tests + lint + gofmt all green.

One thing I couldn't do

I went to reply on the review thread but this comment isn't visible through the GitHub API yet — the most recent comments on the PR are still my four replies from earlier. That usually means it's a pending (unsubmitted) review comment on pjbgf's side, or it was relayed to you out-of-band.

So I held off on posting a reply rather than guess at a thread. Once it's submitted (or if you paste the comment link/ID), I'll post this as the reply:

Good catch — fixed in ffda090. The source URL's entire userinfo is now stripped before it reaches the attestation message, the status output, and the JSON/text result (redactSourceURL). I avoided url.URL.Redacted() on purpose since it only masks the password and would leave a token-in-username form like https://<token>@host/… intact. The fetch path still uses the original URL, so auth is unaffected.

Want me to post that reply once the thread is live, or post it now as a general PR comment?

Already done — the fix is committed as ffda090 and pushed to nodo/convert-sha256. No reply posted, as you asked.

The change is complete and clean. Let me commit and push: