Repository navigation
Validate canonical code-evidence paths in the SDK contract loader #541
Description
Summary
Python finalization now validates canonical codeEvidence[].path, but the shared schema and TypeScript loader still leave it less constrained than ordinary source locations. Imported sealed findings should receive the same repository-relative path checks as newly finalized findings.
Current status
#1522 added Python code-evidence path validation. The remaining findings schema constrains this field only to a nonempty string, while the SDK's explicit path validation covers locations[].path rather than canonical code-evidence paths.
Field-schema probes on current main accept traversal, absolute, and Windows-style paths. The original report describes the corresponding sealed-loader regression.
Regression to preserve
- Copy a synthetic completed-scan fixture.
- Add otherwise valid code evidence with
path: "../../outside.ts". - Update the sealed findings digest in the manifest.
- Call
loadContract()and require rejection of that path.
Include valid repository-relative evidence as a control and verify producer/reader parity.
Remaining work
Enforce the existing canonical source-path contract in the shared schema and/or SDK loader. Preserve valid POSIX filenames; the original blanket ban on colon-containing names should not be carried forward as a new policy.
#542 and #1567 are overlapping open proposals. The implementation should agree with the Python validation already shipped in #1522.
Impact
This is evidence attribution/integrity. codeEvidence.code is embedded in the finding, so the path string alone is not an arbitrary-file-read exploit. It can still cause downstream consumers to display evidence under a path outside the supported repository model.
Activity
[-]Canonical code-evidence paths bypass repository-relative path validation[/-][+]Validate canonical code-evidence paths in the SDK contract loader[/+]mldangelo-oai commentedon Oct 23, 2026
Verified resolved by #1567 on
mainatfe9d77e1c3d973b00209487cc9dd30e42886654e(checked October 24, 2026).Reproduced the requested setup with fresh copies of the synthetic completed-scan fixture: added canonical
codeEvidence, recomputed thefindings.jsonSHA-256 in the manifest, then called the real SDKloadContract()and Python finalizer JSON export. Both reject../../outside.ts, absolute paths, and Windows-style paths. The original traversal case produces:Validation results:
This was local Linux verification using current source and existing installed dependencies; it does not claim full installed-package, full-suite, native Windows, or hosted CI qualification.
The SDK now applies its existing source-path validator to canonical code evidence, so the permissive structural schema does not bypass runtime validation. The separate Unicode-colon filename compatibility mismatch remains follow-up work proposed in #542.
Closing as completed by #1567.