Miner command sanitizer redacts legitimate repo/login names, producing broken "ready" commands

[philluiz2323]

Repo: JSONbored/gittensory · Introduced by: #422 (feat(app): add miner command copy actions)
File: apps/gittensory-ui/src/lib/miner-commands.ts (sanitizeMinerCommand, lines 87–98)
Severity: medium (correctness — copy-paste commands are silently corrupted)

Summary

sanitizeMinerCommand redacts private terms (wallet, hotkey, coldkey,
mnemonic, raw trust, trust score, private reviewability) using a regex
whose value-assignment part is optional, so it matches bare standalone
words. The login and repoFullName are already validated by
safeGitHubLogin / safeRepoFullName, so when a legitimate name contains one of
those words as a token, the built command is corrupted — yet still marked
copyable: true, state: "ready". The user copies a command with [redacted]
in place of their real login/repo. In a Bittensor/crypto ecosystem, repos named
wallet / hotkey / trust-score are common, so the collision is likely.

Evidence

// apps/gittensory-ui/src/lib/miner-commands.ts:94
.replace(
  /\b(?:wallet|hotkey|coldkey|mnemonic|raw[-_\s]?trust|private[-_\s]?reviewability|trust[-_\s]?score)\b(?:\s*[:=]\s*(?:"[^"]*"|'[^']*'|[^\s"'`,;)]+))?/gi,
  "[redacted]",
)

The trailing (?:\s*[:=]\s*…)? (the actual key=value / key:value secret
form) is optional (?), so a bare word like wallet matches and is
redacted on its own — even though safeRepoFullName already guarantees the
value is a clean owner/repo string with no secret/path.

Reproduction (verified)

buildMinerCommandActions(...) output:

input	preflight command	copyable / state
repo metamask/wallet-adapter	… --repo metamask/[redacted]-adapter …	true / ready
login wallet	… --login [redacted] …	true / ready
login trust-score, repo octo/hotkey	… --login [redacted] --repo octo/[redacted] …	true / ready

So a contributor on a repo named wallet-adapter (or with login wallet) is
handed a broken command marked ready-to-run; pasting it fails because the real
repo/login was replaced with [redacted].

Why it's wrong

login and repoFullName are validated to safe character sets before the
command is built (safeGitHubLogin / safeRepoFullName), so they cannot carry
secrets or local paths. The bare-word private-term redaction therefore can only
ever damage legitimate names; it provides no additional safety for these
already-validated inputs.

Test status

No test locks in the current behavior. test/unit/miner-dashboard-commands.test.ts:68
feeds /Users/private/hotkey and /home/private/wallet/repo, but both are
rejected by validation (they contain /) and fall back to your-login /
owner/repo — so the assertion passes via the fallback, never exercising a
valid name that contains a redacted word.

Suggested fix

Make the assignment form required so only actual term=value / term: value
secret leakage is redacted, not bare names:

.replace(
  /\b(?:wallet|hotkey|coldkey|mnemonic|raw[-_\s]?trust|private[-_\s]?reviewability|trust[-_\s]?score)\b\s*[:=]\s*(?:"[^"]*"|'[^']*'|[^\s"'`,;)]+)/gi,
  "[redacted]",
)

(Alternatively, since the command is assembled entirely from constants plus
already-validated login/repo, drop the bare-word redaction from this path
altogether and keep only the local-path scrub for defense in depth.)

Add a fixture with repo metamask/wallet-adapter and login wallet asserting
the command still contains the real names and stays runnable.