Fix: reject files: paths that escape the project root (High: info disclosure)

[0xLeif]

Summary

Fixes a High info-disclosure bug found while dogfooding: a spec's files: entries had no path containment, so an entry resolving outside the project root (absolute path, .., or an in-repo symlink pointing out) was validated — the out-of-root file counted as covered and its exported identifiers leaked into check/score/diff output, PR comments, and the MCP tools.

Fix (closes the whole class)

• source_within_root(root, file) (shared pub(crate) guard) canonicalizes both the root and the resolved path (resolving .. and symlinks) and requires the file to sit inside the canonical root.
• Applied at every site that reads a files: entry's content and extracts identifiers:
  • validate_spec (check) — reports out-of-root entries as an error and skips extraction
  • score (and the MCP score tool)
  • check --fix (both export-collection loops — it persists identifiers into the spec)
  • diff
  • new
• compute_coverage needs no guard: it enumerates real files under source_dirs and uses files: only as a membership set, so an out-of-root path contributes zero LOC (verified: a 20k-line out-of-root file → <100 LOC).

Why class-wide

The first version guarded only validate_spec; review then reproduced the identical leak through specsync score. Rather than patch one site, the guard is now a single shared helper applied at all extraction sites.

Verified

• Real CLI: an in-repo symlink to /etc/passwd is rejected, the spec fails (not a silent pass), no passwd identifiers leak.
• Unit tests: absolute + .. escapes rejected with no export leak; score on an out-of-root file no longer leaks identifiers into suggestions.
• Repo's own 60 specs still pass at 100% (no over-blocking); full suite (658 unit + 149 integration), clippy, fmt clean.

Known lower-severity follow-up (not in scope)

depends_on .exists() probes (validator/report/stale/scoring) are an existence-oracle only — they reveal a boolean, not identifiers. Happy to extend containment there separately.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces path validation checks to ensure that source files referenced in specifications resolve within the project root, preventing path traversal and information disclosure vulnerabilities. It adds a helper function source_within_root and corresponding unit tests. The reviewer pointed out a potential security bypass in the helper function's fallback behavior when canonicalization fails, suggesting a fail-closed approach by checking if the file exists instead of unconditionally returning true.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The current fallback behavior of returning true when canonicalization fails is a potential security bypass (fail-open). If an attacker can trigger a canonicalization failure on either root or full (for example, if root is unreadable/deleted, or if there is a temporary filesystem/I/O error, or if a path contains special characters that fail canonicalization but can still be read), the function will return true, allowing the path containment check to be bypassed and potentially leaking files.

To make this check fail-secure (fail-closed) while still allowing the existence check to handle non-existent files with a better error message, we can return !full.exists() on failure. This ensures that if the file actually exists but cannot be verified to be within the root, it is safely rejected.

Suggested change

	match (root.canonicalize(), full.canonicalize()) {
	(Ok(canon_root), Ok(canon_full)) => canon_full.starts_with(&canon_root),
	_ => true,
	}
	match (root.canonicalize(), full.canonicalize()) {
	(Ok(canon_root), Ok(canon_full)) => canon_full.starts_with(&canon_root),
	_ => !full.exists(),
	}

[github-actions]

✅ Corvin says...

      _
    <(^\  .oO(Caw! ^v^)
     |/(\
      \(\\
      " "\\

"Caw! Your code sparkles like a dropped french fry."

CI Summary

Check	Status
Validate action.yml	✅ Passed
Dependency Audit	✅ Passed
Code Coverage	✅ Passed
Format Check	✅ Passed
Docs Site	✅ Passed
Spec Validation	✅ Passed
Tests (build, test, clippy)	✅ Passed
VS Code Extension	✅ Passed

📋 Spec Validation Details

✅ SpecSync: Passed

Metric	Value
Specs checked	60
Passed	60
Errors	0
Warnings	0
File coverage	100% (76/76)
LOC coverage	100% (34846/34846)

---

Generated by specsync · Run specsync check --format github to reproduce

---

_{Powered by corvid-pet}

[github-actions]

✅ Corvin says...

      _
    <(^\  .oO(Caw! ^v^)
     |/(\
      \(\\
      " "\\

"Caw! Your code sparkles like a dropped french fry."

CI Summary

Check	Status
Validate action.yml	✅ Passed
Dependency Audit	✅ Passed
Code Coverage	✅ Passed
Format Check	✅ Passed
Docs Site	✅ Passed
Spec Validation	✅ Passed
Tests (build, test, clippy)	✅ Passed
VS Code Extension	✅ Passed

📋 Spec Validation Details

✅ SpecSync: Passed

Metric	Value
Specs checked	60
Passed	60
Errors	0
Warnings	0
File coverage	100% (76/76)
LOC coverage	100% (34910/34910)

---

Generated by specsync · Run specsync check --format github to reproduce

---

_{Powered by corvid-pet}

[github-actions]

✅ Corvin says...

      _
    <(^\  .oO(Caw! ^v^)
     |/(\
      \(\\
      " "\\

"Caw! Your code sparkles like a dropped french fry."

CI Summary

Check	Status
Validate action.yml	✅ Passed
Dependency Audit	✅ Passed
Code Coverage	✅ Passed
Format Check	✅ Passed
Docs Site	✅ Passed
Spec Validation	✅ Passed
Tests (build, test, clippy)	✅ Passed
VS Code Extension	✅ Passed

📋 Spec Validation Details

✅ SpecSync: Passed

Metric	Value
Specs checked	60
Passed	60
Errors	0
Warnings	0
File coverage	100% (76/76)
LOC coverage	100% (34920/34920)

---

Generated by specsync · Run specsync check --format github to reproduce

---

_{Powered by corvid-pet}