Skip to content

fix(scripts): don't reject miner package source files merely named with "secret"#8266

Merged
JSONbored merged 1 commit into
mainfrom
fix/miner-package-secret-filter-overbreadth
Jul 23, 2026
Merged

fix(scripts): don't reject miner package source files merely named with "secret"#8266
JSONbored merged 1 commit into
mainfrom
fix/miner-package-secret-filter-overbreadth

Conversation

@JSONbored

Copy link
Copy Markdown
Owner

Summary

scripts/check-miner-package.ts's FORBIDDEN_PATH filter matched the keyword secret (or private...key) anywhere in a packed file's path -- including inside a legitimately-named .js/.ts source file whose purpose is implementing secret-handling logic, not a file that itself contains a leaked value.

Caught firsthand while shipping #8263: a new file named tenant-secret-resolution.ts failed test/unit/check-miner-package.test.ts > passes on the real miner workspace package purely because of its name, and had to be renamed to tenant-credential-resolution.ts to unblock that PR. This fixes the filter itself instead of leaving every future contributor to rediscover the same trap.

Fix

Splits the filter into two concerns:

  • Exact-name dotfiles (.env, .npmrc, .dev.vars) stay forbidden regardless of extension -- these files' entire purpose is almost always credentials.
  • The keyword heuristic (secret, private...key, .pem) now only applies to non-source files. .js/.ts (including .d.ts) are exempt.

This doesn't weaken real protection: a genuinely leaked secret value in any file, source or not, is already caught unconditionally by the separate FORBIDDEN_CONTENT scan (scripts/forbidden-content.ts, applied to every packed file's content regardless of extension or name). The keyword-based FORBIDDEN_PATH check was only ever a coarse, filename-based backstop aimed at stray credential-shaped files like .pem/secrets.json -- it was never meant to (and shouldn't) block descriptively-named source code.

Tests

  • A source file named with "secret" or "private key" in it is now accepted (given otherwise-valid content and package structure).
  • A non-code file whose name suggests it IS a secret (my-private-key.pem, config/secrets.json) is still rejected.
  • The exact-name dotfiles (.env/.npmrc/.dev.vars) are still rejected regardless of this change.

Verified: tsc --noEmit --incremental false clean, real npx tsx scripts/check-miner-package.ts dry-run against the actual workspace passes, full test/unit/check-miner-package.test.ts suite green (17/17, up from 14), git diff --check clean.

Test plan

  • tsc --noEmit --incremental false
  • npx tsx scripts/check-miner-package.ts (real dry-run)
  • npx vitest run test/unit/check-miner-package.test.ts (17/17)
  • git diff --check

…th "secret"

check-miner-package.ts's FORBIDDEN_PATH filter matched the keyword "secret"
(or "private...key") anywhere in a path, including inside legitimately-named
.js/.ts source files -- caught while shipping PR #8263, whose
tenant-secret-resolution.ts had to be renamed to tenant-credential-resolution.ts
to work around it.

Splits the filter: exact-name dotfiles (.env/.npmrc/.dev.vars) stay forbidden
regardless of extension, and the keyword heuristic now only applies to
non-source files. Source files are exempt because a real leaked secret VALUE
is already caught unconditionally by the separate FORBIDDEN_CONTENT scan
regardless of filename -- the keyword check was only ever a coarse,
filename-based backstop for stray credential-shaped files like .pem/.json.
@superagent-security

Copy link
Copy Markdown
Contributor

Superagent didn't find any vulnerabilities or security issues in this PR.

@JSONbored JSONbored self-assigned this Jul 23, 2026
@codecov

codecov Bot commented Jul 23, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.15%. Comparing base (264f26a) to head (e6b3cf5).
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #8266   +/-   ##
=======================================
  Coverage   92.15%   92.15%           
=======================================
  Files         786      786           
  Lines       78860    78860           
  Branches    23801    23800    -1     
=======================================
  Hits        72676    72676           
  Misses       5062     5062           
  Partials     1122     1122           
Flag Coverage Δ
shard-1 53.89% <ø> (ø)
shard-2 50.22% <ø> (ø)
shard-3 57.25% <ø> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

@loopover-orb loopover-orb Bot added the gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier. label Jul 23, 2026
@loopover-orb

loopover-orb Bot commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Warning

⏸️ LoopOver review result - manual review recommended

Review updated: 2026-07-23 17:12:43 UTC

2 files · 2 blockers · CI green · clean

⏸️ Suggested Action - Manual Review

  • AI review could not be completed: The dual-model AI review did not return a usable verdict for this change.

Review summary
AI review could not be completed for this PR head. LoopOver is holding this PR for manual review instead of relying on deterministic signals alone.

Nits — 1 non-blocking
  • AI review could not be completed — The gate is held for a human reviewer rather than passed automatically; it re-evaluates on the next update.

Concerns raised — review before merging

  • No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.
  • Maintainer requires a linked issue: This repo's maintainer focus manifest requires every PR to reference a tracked issue. — Link the relevant issue (for example Closes #123) before opening the PR.
📋 Copy for AI agents — paste into your coding agent
Fix the following blocker(s) from this PR review:

1. No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue: This repo's maintainer focus manifest requires every PR to reference a tracked issue. — Link the relevant issue (for example `Closes #123`) before opening the PR.

Decision drivers

  • ❌ Code review — 2 blockers (no AI review ran — blocker is from a non-AI gate check)
  • ❌ Gate result — Blocking (Repo-configured hard blocker found.)
Context & advisory signals — never blocks the verdict
Signal Result Evidence
Linked issue ⚠️ Missing No linked issue or no-issue rationale found.
Related work ✅ No active overlap found No same-issue or scoped active PR overlap found.
Change scope ✅ 20/20 Low review scope from cached public metadata (no linked issue context).
Validation posture ✅ 25/25 PR body includes validation/test evidence.
Contributor workload ✅ 10/10 Author activity: 14 registered-repo PR(s), 14 merged, 247 issue(s).
Contributor context ✅ Confirmed Gittensor contributor JSONbored; Gittensor profile; 14 PR(s), 247 issue(s).
Improvement ✅ Minor risk: clean · value: minor
Review context
  • Author: JSONbored
  • Role context: owner (maintainer lane)
  • Public audience mode: oss maintainer
  • Lane context: Repository is configured for direct PR review.
  • Public profile languages: Python, TypeScript, Ruby, Go, MDX, Shell, Solidity, JavaScript
  • Official Gittensor activity: 14 PR(s), 247 issue(s).
  • PR-specific overlap: none found.
Contributor next steps
  • Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.
  • Then work through the remaining 2 steps in the Signals table above.
Signal definitions
  • Related work = same linked issue, overlapping active PRs, or title/path similarity.
  • Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
  • Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
  • Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
  • Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.
🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

  • @loopover ask &lt;question&gt; answers contribution-quality Q&A with source citations and freshness.
  • @loopover chat &lt;question&gt; answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
  • A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed


💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

  • Re-run LoopOver review

@loopover-orb loopover-orb Bot added the manual-review Gittensor contributor context label Jul 23, 2026
@JSONbored
JSONbored merged commit e46031a into main Jul 23, 2026
14 checks passed
@JSONbored
JSONbored deleted the fix/miner-package-secret-filter-overbreadth branch July 23, 2026 21:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier. manual-review Gittensor contributor context

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant