You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most identity-consuming components use BUZZ_PRIVATE_KEY (buzz-cli declares it as a required arg env at crates/buzz-cli/src/lib.rs:85; the ACP/MCP shim passes it to shell children; buzz-admin reads it). The git credential helper alone resolves identity from NOSTR_PRIVATE_KEY (crates/git-credential-nostr/src/lib.rs:51, load_key()), falling back to git config nostr.keyfile.
A user who exports the ecosystem-standard BUZZ_PRIVATE_KEY gets no error and no warning: the helper silently signs as the key file's identity instead, and the resulting server rejection (pre-receive hook declined) is indistinguishable from a permissions problem with the intended identity.
Steps to reproduce
Configure git config nostr.keyfile with identity A (a channel member).
export BUZZ_PRIVATE_KEY=<identity B's key> where B is the repo owner.
Run an owner-gated operation, e.g. git push <relay-repo-url> :refs/heads/some-branch.
The push is rejected exactly as it would be for identity A — the env var was never consulted.
Expected behavior
In order of preference (deferring to maintainers on direction):
The helper warns on stderr when BUZZ_PRIVATE_KEY is set but unused — pure DX improvement, no new security surface, and it breaks the silent wrong-identity trap.
The naming difference is documented where the helper is introduced.
Optionally, the helper also accepts BUZZ_PRIVATE_KEY (keeping NOSTR_PRIVATE_KEY for back-compat) — noting fix(security): migrate MCP private-key handoff to keyfile pattern #3478 moved toward keyfile handoff for env-borne keys, so an env alias may be against the intended direction; happy to follow whichever pattern is preferred.
I am glad to submit a PR for the chosen direction (DCO sign-off and Conventional Commits understood).
Version and platform
Buzz version: 0.5.3 (behavior also present at current main — crates/git-credential-nostr/src/lib.rs:51)
OS: macOS 15
Logs / additional context
Hit while performing an owner-signed ref deletion on a relay-hosted repo: the silent fallback cost a debugging round and a key-file-swap workaround before a source read revealed the variable-name difference. Prior-art searched across open/closed issues and PRs (NOSTR_PRIVATE_KEY, BUZZ_PRIVATE_KEY, git-credential-nostr, credential-helper env synonyms) — closest matches #2316 (silent no-credentials on old git) and #3478 (keyfile migration) do not cover this.
Describe the bug
Most identity-consuming components use
BUZZ_PRIVATE_KEY(buzz-clideclares it as a required arg env atcrates/buzz-cli/src/lib.rs:85; the ACP/MCP shim passes it to shell children; buzz-admin reads it). The git credential helper alone resolves identity fromNOSTR_PRIVATE_KEY(crates/git-credential-nostr/src/lib.rs:51,load_key()), falling back togit config nostr.keyfile.A user who exports the ecosystem-standard
BUZZ_PRIVATE_KEYgets no error and no warning: the helper silently signs as the key file's identity instead, and the resulting server rejection (pre-receive hook declined) is indistinguishable from a permissions problem with the intended identity.Steps to reproduce
git config nostr.keyfilewith identity A (a channel member).export BUZZ_PRIVATE_KEY=<identity B's key>where B is the repo owner.git push <relay-repo-url> :refs/heads/some-branch.Expected behavior
In order of preference (deferring to maintainers on direction):
BUZZ_PRIVATE_KEYis set but unused — pure DX improvement, no new security surface, and it breaks the silent wrong-identity trap.BUZZ_PRIVATE_KEY(keepingNOSTR_PRIVATE_KEYfor back-compat) — noting fix(security): migrate MCP private-key handoff to keyfile pattern #3478 moved toward keyfile handoff for env-borne keys, so an env alias may be against the intended direction; happy to follow whichever pattern is preferred.I am glad to submit a PR for the chosen direction (DCO sign-off and Conventional Commits understood).
Version and platform
main—crates/git-credential-nostr/src/lib.rs:51)Logs / additional context
Hit while performing an owner-signed ref deletion on a relay-hosted repo: the silent fallback cost a debugging round and a key-file-swap workaround before a source read revealed the variable-name difference. Prior-art searched across open/closed issues and PRs (
NOSTR_PRIVATE_KEY,BUZZ_PRIVATE_KEY,git-credential-nostr, credential-helper env synonyms) — closest matches #2316 (silent no-credentials on old git) and #3478 (keyfile migration) do not cover this.