fix: apply ECMA regex boundaries in Trust Record validation

[imran-siddique]

What this changes

The Python verifier accepts signed records whose subjects end with LF, CR, U+2028 or U+2029, although the published subject pattern rejects those values under ECMA-262. URI validation also accepts a final LF. This change rejects those records as schema-invalid.

Adapt the four pattern forms shipped in TRACE v0.2 to Python with a strict end anchor, the ECMA line-terminator exclusions for dot, and ASCII digits for \d. Keep the published schema and error paths unchanged. A test requires every shipped pattern to have an explicit adapter; this is not a general ECMA regex translator. The local URI checker rejects literal line terminators while accepting percent-encoded characters.

Closes #379. Thanks to @chernistry for the reproducer.

Type of change

Python verifier bug fix; no normative or schema change.

Spec section

TRACE v0.2 section 3.3, schema validation; JSON Schema 2020-12 section 6.3.3 and ECMA-262 regular expressions.

Validation

• Initial regressions before the fix: 21 failed, 10 controls passed.
• After the fix: 302 focused schema, URI and signing tests passed.
• Independent Node 24 comparison: all 520 results agree across the four published pattern forms. The comparison test skips explicitly if Node is unavailable.
• Full Windows run: 2,039 passed, 6 skipped, and the same five generator-fixture failures previously reproduced on unchanged ccbd5b9 (conformance, gap-disclosure, canonicalization-boundary, delegation-link, verifier-compatibility).
• Ruff, mypy (13 source files), repository style check and git diff --check passed.

Tests cover signed records, middle and trailing line terminators, all eight URI fields, digest/signature end anchors, Unicode digit rejection in durations, valid Unicode subjects, schema inventory and isolation from jsonschema's global validators. The Windows environment uses pinned development requirements plus colorama==0.4.6.

The schema's negated SPIFFE authority class still permits line terminators there; a control preserves that published behavior. Tightening that rule would require a separate schema decision. This PR also shares the URI checker with #387, so the two guards must be retained when those branches are combined.

Checklist

• DCO sign-off on the commit.
• No normative change requiring a changelog entry or comment period.

[lywinged]

Checked at e77f498 against 3ddcbbf, merges clean, 302 tests pass, CI green. All four records
from #379 are rejected here and all four verify on 3ddcbbf.

I tried to make half of this unnecessary, because the four records all carry their terminator at
the end and an end anchor alone looks sufficient. It is not: keep $ to \Z and remove the dot
substitution, and two of the four still verify, because U+000D and U+2028 inside subject are
matched by .+ rather than by the anchor. Your own tests fail 16 on that variant, including
test_shipped_pattern_results_match_javascript. That is the counterfactual run from the other
side, and it passes.

Two things worth a line each, neither blocking.

An unadapted pattern is a bare KeyError out of the validator. _ecma_pattern does
_PYTHON_PATTERNS[pattern] with no fallback, so a schema pattern with no adapter gives
KeyError: "\'^[a-z]+$\'" rather than anything a caller can act on.
test_every_shipped_pattern_has_an_explicit_adapter means CI catches it before it ships, and the
inventory is currently exact. But the runtime shape is an exception where a verdict was promised,
which is the class your own 386 removes in this same batch. One raise RuntimeError(f"no ECMA adapter for schema pattern {pattern!r}") closes it.

The title is wider than the change. revocation.py's _bundle_validator() is a separate
plain Draft202012Validator, and trace-revocation-bundle.json carries ^[A-Za-z0-9_-]+$ at
/properties/sig/properties/value. On this branch a bundle whose sig.value ends in U+000A is
still accepted by that schema; U+000D is not, because the class has no .. One character, one
member, two schemas, and it lands on bundle_signature_invalid a moment later, so the severity is
low. #379 names only trace-claim.json, so the change is inside the issue; it is "ECMA regex
boundaries in TRACE validation" in the title that reaches one place further.

Combining it with 387

The two conflict in src/agentrust_trace/validate.py and in
tests/test_uri_formats_are_enforced.py, which is the pair your description warns about. Five
resolutions, run:

resolution	#379	#380	tests
both bodies in one is_uri, raises=ValueError kept	fixed	fixed	296 pass
keep 388's is_uri, union the test files	fixed	back	34 fail
keep 387's is_uri, union the test files	back, 4 of 4	fixed	35 fail
both def is_uri left in place, second shadowing the first	1 of 4 back	fixed	9 fail
both bodies, raises=ValueError dropped	fixed	escapes as AddressValueError	34 fail

The catch is that those failure counts depend on resolving the test file by union. Resolve
both files the same way, which is what --ours or --theirs does, and the detector goes with the
guard: keeping 388 throughout is 129 passed and 0 failed with #380 restored, and keeping 387
throughout is 167 passed and 0 failed with #379 restored on all four records. Green, with the bug
back. That is the resolution I would guard against, not the shadowing one.

The one I ran and would suggest: a single is_uri with the line-terminator check first, then
base_uri_checker.conforms, then the bracket literal, decorated
@checker.checks("uri", raises=ValueError). Both issues closed, 296 passed across 387's URI
file, 388's URI file and the regex file.

Separately, across the ten pairs from 383, 386, 387, 388 and 390, two others conflict: 383 with
386 in CHANGELOG.md, and 383 with 390 in tests/test_sign.py. Both trivial. 390 merges clean
against 386, 387, 388 and against 389.

---

---

What I could not check

• Windows. Every runs-on: in .github/workflows/ is ubuntu-latest and there is no Windows
  job, so my Linux run and CI are one instrument rather than two. Your own experiment on 383,
  that the same five generator failures reproduce with the production fix removed, is stronger
  than anything I can run here.
• The published agentrust-trace wheel. Everything above is against repository trees.

[imran-siddique]

@lywinged #387 is merged. I resolved #388 against main with one URI checker: line-terminator check first, then the base checker, then the IPv6 literal check, with raises=ValueError retained. Both test sets are preserved.

The combined URI and regex suites pass all 245 tests. Removing the IPv6 guard causes 34 failures, removing the line-terminator guard causes 9, and removing the exception conversion causes 34. Full Windows suite: 2,159 passed, 6 skipped and the same five known generator-fixture failures. Ruff, mypy and style checks pass. Fresh CI is running.

I narrowed the title to Trust Record validation, as you suggested. The unknown-pattern diagnostic remains a separate nonblocking follow-up; this merge does not change that behavior.

Could you confirm this resolution and #383 at 519cea1? On #383, the only manual conflict resolution keeps both changelog entries; the merged signing and revocation tests pass all 219 cases. GitHub dismissed the earlier approvals after these updates. Both PRs will wait for review and passing checks before merging.

[lywinged]

Rechecked both heads on Linux/Python 3.12.

#388 at f31e974: The single URI checker preserves both guards, their order, and raises=ValueError. Both test sets are intact. All 245 URI and regex tests pass. Removing the IPv6 guard, line-terminator guard, and exception conversion reproduces exactly 34, 9, and 34 failures respectively.

#383 at 519cea1: The only manual conflict resolution is in CHANGELOG.md, and both entries are preserved. The nonce implementation and signing tests are unchanged from 7897d82. All 219 signing and revocation tests pass.

CI was green on both checked heads. No blocking issues found. The unknown-pattern diagnostic can remain a separate follow-up.