Security: credentials in git remote URL captured verbatim into published lineage records

[christophergeyer]

Summary

When a project's origin remote URL embeds credentials (e.g. https://user:TOKEN@github.com/..., a common pattern for CI/automation push auth), roar register records the remote URL verbatim — credentials included — into the lineage/session published to GLaaS. Under --anonymous public scope this writes the secret into a world-readable record.

Why it's easy to hit

roar register itself pushes a git tag to origin to satisfy the "commit reachable on a remote" reproducibility check. That push needs write auth on the remote, and a natural way to supply it is embedding a token in the remote URL — which then gets captured into the published record.

Impact

• Any credential in git remote get-url origin (token / password) lands in the published lineage.
• With anonymous + public scope, the record is world-readable.
• There is currently no CLI path to redact or delete an anonymous published record, so the leak cannot be remediated client-side — the only mitigation is rotating/revoking the credential.

Suggested fixes

1. Sanitize remote URLs before recording/publishing — strip userinfo (user[:password]@) from HTTP(S) remotes. Record https://github.com/org/repo.git, never https://user:token@....
2. Scrub known token patterns as defense-in-depth (e.g. gh[opsu]_…, github_pat_…, xox[baprs]-…) from any captured/published fields.
3. Provide a redaction/delete path for published records — including anonymous ones, e.g. return a management/deletion token at publish time — so an accidental leak can be pulled back.
4. Warn at register time if the resolved remote URL contains embedded credentials.

Workarounds (for docs meanwhile)

Authenticate the tag push without putting the token in the URL — e.g. GIT_ASKPASS, a credential helper, or an SSH-form remote — so git remote get-url origin stays credential-free.

Environment

• roar 0.3.6