Pre-commit secret-scan hook: false positive on prvkey field accesses #35

New issue

Open

opened 2026-05-02 13:38:39 +00:00 by padreug · 0 comments

padreug commented

2026-05-02 13:38:39 +00:00

Owner

The pre-commit hook that scans for secrets (pattern: PRIVATE KEY) flags field-access references like authService.user.value.prvkey and auth.currentUser.value?.prvkey as potential secrets. These are TypeScript property accesses on the user object — not literal key material — and they're scattered across the codebase (e.g. src/modules/market/composables/useMarket.ts:402-413).

Reproduction

Stage any unrelated change to src/modules/market/composables/useMarket.ts and run git commit:

ERROR: potential secret in src/modules/market/composables/useMarket.ts (pattern: PRIVATE KEY)
commit blocked: 1 potential secret(s) detected
false positive? use: git commit --no-verify

The flagged content is unchanged from previous commits — the hook scans the whole file, not just the diff hunks.

Impact

Forces --no-verify on legitimate commits that touch this file or any other file referencing the prvkey field. That defeats the hook's value (it's habituating bypassing) and conflicts with the policy of never skipping hooks.

Last triggered: commit 73b67d2 (feat(market): public browse mode + auth toast at checkout), bypassed with --no-verify.

Suggested fixes

Pick one or combine:

Allowlist the field name. Add prvkey to whatever ignore list the hook uses (likely a .gitleaks.toml, .secrets.baseline, or .detect-secrets.yaml file at the repo root — needs locating).
Scan the diff, not the file. Most secret scanners support --staged / unified-diff mode so they only look at lines being added.
Tighten the PRIVATE KEY regex so it requires the literal Bitcoin/Nostr/PEM prefix (e.g. -----BEGIN PRIVATE KEY----- or nsec1...) rather than just the substring prvkey.
Rename the field. prvkey → privateKey (long-form) elsewhere in the codebase so the substring no longer matches the hook's pattern. Larger blast radius but produces a hook that stays useful.

Notes

The prvkey field is on the NostrUser interface (likely in src/lib/api/lnbits.ts or src/modules/base/auth/types.ts); it stores the user's actual Nostr private key in browser memory. So the hook's intent is right — keep an eye on this field — but the line-level heuristic is wrong.
Issue tracked from the market public-browse work; not blocking that change.

The pre-commit hook that scans for secrets (pattern: `PRIVATE KEY`) flags field-access references like `authService.user.value.prvkey` and `auth.currentUser.value?.prvkey` as potential secrets. These are TypeScript property accesses on the user object — not literal key material — and they're scattered across the codebase (e.g. `src/modules/market/composables/useMarket.ts:402-413`). ## Reproduction Stage any unrelated change to `src/modules/market/composables/useMarket.ts` and run `git commit`: ``` ERROR: potential secret in src/modules/market/composables/useMarket.ts (pattern: PRIVATE KEY) commit blocked: 1 potential secret(s) detected false positive? use: git commit --no-verify ``` The flagged content is unchanged from previous commits — the hook scans the whole file, not just the diff hunks. ## Impact Forces `--no-verify` on legitimate commits that touch this file or any other file referencing the `prvkey` field. That defeats the hook's value (it's habituating bypassing) and conflicts with the policy of never skipping hooks. Last triggered: commit 73b67d2 (`feat(market): public browse mode + auth toast at checkout`), bypassed with --no-verify. ## Suggested fixes Pick one or combine: 1. **Allowlist the field name.** Add `prvkey` to whatever ignore list the hook uses (likely a `.gitleaks.toml`, `.secrets.baseline`, or `.detect-secrets.yaml` file at the repo root — needs locating). 2. **Scan the diff, not the file.** Most secret scanners support `--staged` / unified-diff mode so they only look at lines being added. 3. **Tighten the `PRIVATE KEY` regex** so it requires the literal Bitcoin/Nostr/PEM prefix (e.g. `-----BEGIN PRIVATE KEY-----` or `nsec1...`) rather than just the substring `prvkey`. 4. **Rename the field.** `prvkey` → `privateKey` (long-form) elsewhere in the codebase so the substring no longer matches the hook's pattern. Larger blast radius but produces a hook that stays useful. ## Notes - The `prvkey` field is on the `NostrUser` interface (likely in `src/lib/api/lnbits.ts` or `src/modules/base/auth/types.ts`); it stores the user's actual Nostr private key in browser memory. So the hook's intent is right — keep an eye on this field — but the line-level heuristic is wrong. - Issue tracked from the market public-browse work; not blocking that change.

padreug referenced this issue from a commit

2026-05-02 14:29:41 +00:00

feat(market): rebrand fallback name + bottom navigation bar

padreug referenced this issue from a commit

2026-05-02 14:29:41 +00:00

docs(deploy): document path-mode demo deployment + hub URL convention

padreug referenced this issue from a commit

2026-05-03 07:38:55 +00:00

fix(auth): server-validate URL tokens + tighten guards (closes #36)

padreug referenced this issue

2026-05-07 10:27:10 +00:00

feat(layout): adopt unified AppShell across hub + 7 standalones (Phase B) #52