fix(preset): allow symlinked extends targets outside the config directory

[fohte]

Purpose

• A relative-path extends reference (./foo.yml, ...) whose symlink target points outside the directory of the config file fails with path traversal detected: './foo.yml' escapes the base directory.
  • Overlay patterns that drop a symlink into the config directory to pull in a preset from elsewhere do not work.
  • The same file referenced through an absolute ~/ path is accepted, so rejecting only the relative form has no consistent justification.

Reproduction steps

mkdir -p /tmp/runok-repro/config /tmp/runok-repro/overlay
echo 'rules: []' > /tmp/runok-repro/overlay/extra.yml
ln -s /tmp/runok-repro/overlay/extra.yml /tmp/runok-repro/config/extra.yml
cat > /tmp/runok-repro/config/runok.yml <<'YAML'
extends:
  - ./extra.yml
YAML
runok check --config /tmp/runok-repro/config/runok.yml 'echo hi'
# => config error: preset error: invalid reference:
#    path traversal detected: './extra.yml' escapes the base directory

Approach

• Restrict the check on relative and ~/ extends references to a purely lexical evaluation of the reference string.
  • Decide on the path text alone whether .. segments escape the resolution root; do not follow the resolved path's symlinks.
  • A reference without .. is accepted regardless of where its symlink target points.
• ..-based escapes such as ../../etc/passwd or ~/../../etc/passwd continue to be rejected.

Design decisions

Validation threat model

Decision	Design	Pros	Cons
Chosen	Reject only ..-based escapes by lexically evaluating the reference string	extends: already accepts absolute paths without restriction, so a filesystem sandbox around symlink targets carries no meaning in the threat model (anyone who can author extends: can also write any absolute path). A ..-segment check is enough as a typo-detection safety guard.	Does not prevent reads through a planted symlink, but this matches the existing acceptance of absolute paths.
Rejected	Keep the canonicalize-based check and add an opt-out config flag	Preserves the expectation that what extends: resolves to stays inside the root, even through symlinks.	Inconsistent with extends: already accepting absolute paths. The flag only adds cognitive overhead for users.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.06%. Comparing base (9dd0e7d) to head (62d9ad4).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #346      +/-   ##
==========================================
- Coverage   89.07%   89.06%   -0.02%     
==========================================
  Files          53       53              
  Lines       12657    12661       +4     
==========================================
+ Hits        11274    11276       +2     
- Misses       1383     1385       +2     

Flag	Coverage Δ
Linux	88.88% <100.00%> (-0.01%)	⬇️
macOS	90.15% <100.00%> (-0.05%)	⬇️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gemini-code-assist]

Code Review

This pull request updates the extends: path resolution to use lexical normalization instead of filesystem canonicalization, allowing symlinks to point outside the base directory while still preventing .. traversal. Documentation and tests have been updated to reflect this change. A security concern was raised regarding the validate_within function, which may incorrectly permit path traversal if the root path is empty; a specific code improvement was suggested to address this vulnerability.