fix(enrichment): bound EOL runtime lookups

[JSONbored]

Motivation

• The EOL analyzer could extract an unbounded number of runtime pins from attacker-controlled patches and performed one endoflife.date fetch per distinct product:version, which allowed request amplification against the third‑party calendar API and risked degrading enrichment availability.
• The intent is to limit per-request work and ensure product-level caching so identical product calendars are fetched at most once per enrichment request.

Description

• Add per-request caps MAX_EOL_FILES, MAX_EOL_PATCH_LINES, and MAX_EOL_PINS and enforce them in extractVersionPins to bound files scanned, patch lines scanned, and pins returned in a single request (review-enrichment/src/analyzers/eol-check.ts).
• Introduce a cyclesByProduct cache inside scanEol so fetchCycles(product) is invoked at most once per product per request and repeated version lookups reuse the cached calendar.
• Add regression tests to review-enrichment/test/enrichment.test.ts that assert extraction is capped and that scanEol issues only one fetch per product (tests: extractVersionPins: caps attacker-controlled EOL scan input and scanEol: caches endoflife.date cycles per product).
• Change is limited to the review-enrichment EOL analyzer and its tests and preserves existing EOL finding semantics for pins within the new budgets.

Testing

• Ran the package-local tests with cd review-enrichment && npm test, and the review-enrichment test suite passed (all tests in that package succeeded).
• Attempted the full repo gate npm run test:ci locally, but the run could not be completed in this environment due to unrelated tooling/coverage failures (TypeError: jsTokens is not a function in the coverage tooling), so the full CI gate was not verified here.
• Attempted npm audit --audit-level=moderate, but the npm audit endpoint returned 403 Forbidden and the audit check could not be completed in this environment.

---

Codex Task

[superagent-security]

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

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review — safe to merge

2 files · 1 AI reviewers · no blockers · readiness 48/100 · CI green · unknown

✅ Approved — safe to merge

Review summary
This change introduces three module-level caps (`MAX_EOL_FILES=40`, `MAX_EOL_PATCH_LINES=1000`, `MAX_EOL_PINS=80`) in `extractVersionPins` and a `cyclesByProduct` Map in `scanEol` to prevent fetch amplification against endoflife.date. The cap logic is correct: `filesScanned` only increments for files that have patches (patchless files are skipped before the counter, not after), `linesScanned` counts every patch line including context and removals rather than only additions (intentionally conservative), and the product cache correctly stores `null` fetch failures so a failed product is not retried within the same request. Both new regression tests faithfully exercise the cap and the cache-hit semantics.

Nits (5)

• eol-check.ts outer loop: patchless files skip `filesScanned` but are still iterated — a `req.files` array with thousands of patch-free entries traverses the loop unboundedly; `MAX_EOL_FILES` guards patch processing, not outer-loop traversal.
• eol-check.ts `linesScanned`: counting all patch lines (hunk headers, context, removals) rather than `+` lines is a reasonable conservative choice but is non-obvious — a short inline comment would prevent a future reader from treating it as a bug.
• enrichment.test.ts `scanEol: caches` test: `assert.equal(findings.length, 4)` verifies count but not which findings or their statuses; asserting at least one `eol` and one `soon` finding would make the test's intent clearer without much added verbosity.
• eol-check.ts: add a one-line comment on `linesScanned` — e.g., `// counts all lines (context, removals, headers) for a conservative bound` — so the intentional conservatism is self-documenting.
• eol-check.ts: if `req.files` can originate from an untrusted payload with no upstream length cap, add a guard on the outer loop (e.g., bail after iterating `MAX_EOL_FILES * some_multiplier` total entries) to keep the patchless-traversal cost bounded as well.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewers, synthesized
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Review load	❌ 8/20	Readiness component derived from cached public PR metadata and labels; size label size:S.
Validation evidence	❌ 5/25	Cached preflight status is hold.
Open PR queue	❌ 3/10	26 open PR(s), 9 likely reviewable, 17 unlinked.
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 81 PR(s), 297 issue(s).
Gate result	✅ Passing	No configured blocker found.

Nits — 2 non-blocking

• Repository config was not parsed
• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 81 PR(s), 297 issue(s).
• Related work: Titles/paths share 7 meaningful terms. (PR #1537)
• Related work: Titles/paths share 6 meaningful terms. (PR #1545)
• Related work: Titles/paths share 6 meaningful terms. (PR #1554)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Review top overlaps.
• Add scope summary.
• Fix blocker.
• Expect slower review.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.
• Check active issues and PRs before submitting.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Review load = cached public PR metadata such as size labels, changed paths, and preflight status.
• Open PR queue = repo-wide review pressure; it is not a PR quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

Review details

Generated from public PR metadata and the diff. Advisory only; deterministic signals remain authoritative.

This change introduces three module-level caps (`MAX_EOL_FILES=40`, `MAX_EOL_PATCH_LINES=1000`, `MAX_EOL_PINS=80`) in `extractVersionPins` and a `cyclesByProduct` Map in `scanEol` to prevent fetch amplification against endoflife.date. The cap logic is correct: `filesScanned` only increments for files that have patches (patchless files are skipped before the counter, not after), `linesScanned` counts every patch line including context and removals rather than only additions (intentionally conservative), and the product cache correctly stores `null` fetch failures so a failed product is not retried within the same request. Both new regression tests faithfully exercise the cap and the cache-hit semantics.

Nits (5)

• eol-check.ts outer loop: patchless files skip `filesScanned` but are still iterated — a `req.files` array with thousands of patch-free entries traverses the loop unboundedly; `MAX_EOL_FILES` guards patch processing, not outer-loop traversal.
• eol-check.ts `linesScanned`: counting all patch lines (hunk headers, context, removals) rather than `+` lines is a reasonable conservative choice but is non-obvious — a short inline comment would prevent a future reader from treating it as a bug.
• enrichment.test.ts `scanEol: caches` test: `assert.equal(findings.length, 4)` verifies count but not which findings or their statuses; asserting at least one `eol` and one `soon` finding would make the test's intent clearer without much added verbosity.
• eol-check.ts: add a one-line comment on `linesScanned` — e.g., `// counts all lines (context, removals, headers) for a conservative bound` — so the intentional conservatism is self-documenting.
• eol-check.ts: if `req.files` can originate from an untrusted payload with no upstream length cap, add a guard on the outer loop (e.g., bail after iterating `MAX_EOL_FILES * some_multiplier` total entries) to keep the patchless-traversal cost bounded as well.

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review