The xml-sec fork exists for Italy and France, and neither is in the fixtures

[LKSNDRTMLKV]

The workspace carries a forked xml-sec for one reason, and that reason has never been observed passing a test.

What the fork is for

Cargo.toml:

# Vendored one-constant fix: the published crate hard-caps XML node-sets at
# 65536 and the Italian and French trusted lists carry 65540 and 65541, so
# neither verifies. Reported upstream as structured-world/xml-sec#158 — remove
# this stanza and the fork when that ships.
[patch.crates-io]
xml-sec = { git = "https://github.com/odal-node/xml-sec.git", rev = "7daf6028e08bc17f60ac36833d90c9307ca25449" }

Four and five nodes over a 65,536 ceiling. Without the fork, XMLDSig verification of the Italian and French trusted lists fails — not as a bad signature, but as a canonicaliser that stops before the end of the document.

The gap

The trusted-list fixtures are eu-lotl.xml and fi-trusted-list.xml — the Commission's list of lists, and Finland.

IT and FR are not among them. So:

• the fork's justification rests on a bug report, not on a green test;
• nothing in the suite would notice if the fork stopped being applied;
• and nothing would notice if a future fork rebase reintroduced the cap.

Everything else about the trusted-list chain is tested against real published documents, deliberately and well. This is the one claim in it that is asserted rather than demonstrated.

Why "stopped being applied" is a real failure mode, not a hypothetical

crates/dpp-seal/Cargo.toml requires xml-sec = "0.1.16", and the fork is 0.1.16, so the patch currently satisfies the requirement and applies.

Bump that requirement to "0.1.17" — which is exactly what someone will do the day upstream publishes — and the fork's 0.1.16 no longer satisfies it. Cargo then emits an unused patch warning, not an error, and silently resolves to the registry crate.

If upstream 0.1.17 contains the fix, that is the desired outcome and the stanza should go. If it does not, the cap comes back, and the only symptom is two Member States failing verification. Today nothing distinguishes those two cases.

⚠️ The same mechanism broke the [patch] during the core 0.19.0 repin. It is quiet by design.

Upstream status as of 2026-09-12: xml-sec is still at 0.1.16 on crates.io, published 2026-08-29. structured-world/xml-sec#158 has not shipped, so the fork is load-bearing now and for the foreseeable release.

What to do

1. Add Italian and French trusted lists as fixtures, and assert they verify through a verified LOTL.

Same shape as the existing chain tests: take the pointer for the territory out of the verified LOTL, verify the national document against the certificates that pointer names, assert a VerifiedTrustedList. Nothing new is needed beyond the two documents.

These are the two largest documents in the set, so the fetch cap stated at the call site (1 MiB) is worth re-checking against their actual sizes rather than assumed to cover them.

2. Make the fork's absence go red rather than warn.

The tests in step 1 do most of this: remove the [patch.crates-io] stanza and they should fail. Verify that they actually do before trusting them green — a gate that has never failed is not known to work, and this one has a specific failure to reproduce.

Worth considering alongside: a check that the resolved xml-sec source is the git one, so the diagnostic says "the patch is not applied" rather than leaving someone to infer it from two country-named test failures.

3. Keep the exit condition visible.

The stanza comment already names structured-world/xml-sec#158 as the removal trigger. When it ships, the change is: bump the requirement, delete the stanza, delete the fork — and the step-1 tests are what prove the published crate is genuinely fixed rather than assumed to be.

Sequencing

Blocked. crates/dpp-seal/src/trustlist/ and crates/dpp-seal/tests/fixtures/ do not exist on main — they arrive with #294, which cannot merge until dpp-core 0.20.0 is published and this workspace repins (#296).

The work itself needs nothing from core and could be committed onto the #294 branch beforehand, where the dpp-seal suite already runs green in isolation. That is a judgement call about branch size: it adds two large fixtures and a handful of tests to a branch that is already sizeable and waiting on an external event.

Out of scope

The anchor refresh story. EU_LOTL_ANCHOR pins six SHA-256 digests from OJ notice CELEX 52026XC01944, and a pin nobody refreshes will eventually reject a valid LOTL as NotAnchored — failing closed, looking like an outage. That is a real gap and a different one; #295 already flags it as needing design alongside the verifier. Not folded in here.

[LKSNDRTMLKV]

Unblocked. The sequencing note here is satisfied: dpp-core 0.20.0 is published, the repin (#296) merged as #312, and #294 is revived as #316 — green, 14/14, open against main. crates/dpp-seal/src/trustlist/ and its fixtures exist on that branch, so this work has somewhere to land.

The fetch cap is not "worth re-checking" — it already contradicts the fork

This issue asks that the 1 MiB cap be re-checked against the real sizes "rather than assumed to cover them". Checked, and it does not cover them:

MAX_TRUSTED_LIST_BYTES = 1024 * 1024   // 1,048,576 bytes
Italy   2.86 MB   — 2.7× over
France  2.55 MB   — 2.4× over

fetch_trusted_list passes that cap to fetch_text for every national list, and a document over it is refused with SealError::Backend. So the fork's entire purpose is unreachable through this crate's own fetch path. The vendored one-constant fix raises the node-set ceiling so IT and FR verify; the fetcher declines to download them in the first place.

The two documents can still be verified by a caller that obtained the bytes some other way — verify_trusted_list takes &str — but nothing in this crate can supply them.

The cap's own doc comment shows how it happened:

"Measured rather than guessed: the list of lists is about 480 KiB, and national lists have been seen from roughly 140 KiB to over 600 KiB."

That measurement did not include the two largest lists in the set — the same two this fork exists for.

Why nothing caught it

The chain tests read fixtures with include_str! and never call fetch_trusted_list, and MAX_TRUSTED_LIST_BYTES is asserted nowhere. So the cap is exercised by no test at all, and the fork is exercised by no test at all, and the two happen to disagree.

This strengthens step 1 rather than changing it: adding IT and FR as fixtures proves the fork, and a test that goes through the fetch path proves the cap admits them. Both are needed — a fixture-only test would pass with the cap still wrong.

Suggested cap

Whatever is chosen should be stated against the measured maximum rather than the nearest round number, and the doc comment should name the two documents that set it, so the next person raising it knows what it was sized for. 4 MiB covers today's largest with headroom; trusted lists only grow, and the cap exists to bound a hostile response rather than to be tight.

[LKSNDRTMLKV]

Closed by #319, with two corrections to this issue's premise worth recording.

"Only Italy and France" was already stale. Re-measured across every list the LOTL points at on 2026-09-15, four are over the node-set ceiling — FR 65 541, CZ 65 543, IT 65 540, ES 65 543 — and all four verify with the fork. Czechia and Spain crossed since the measurement here was taken. Byte size does not predict the count, so the affected set is a measurement rather than a rule.

Germany fails on a different ceiling the fork does not raise — XML nodes exceeds policy maximum 100000: got 100001, one node over. Upstream #158 would not close it. Filed as #320, not urgent: nothing consumes the verifier yet and the failure is the safe direction.

The fetch cap did contradict the fork, as this issue suspected — and worse than suspected. It refused every document over 1 MiB, so the fork's purpose was unreachable through the crate's own path. Now 8 MiB, sized against the whole measured set including Germany at 5.11 MiB, and enforced as a compile-time assertion beside the constant rather than a test.

The documents are not committed. ~5 MB to demonstrate one claim was a poor trade, especially once the claim turned out to cover four documents so any committed sample is arbitrary. They live under tests/fixtures/local/ (git-ignored) with a README on fetching them, and the test skips loudly when absent. The regression guard — the_patched_xml_sec_is_the_one_that_resolved, which reads Cargo.lock — needs no documents and runs everywhere. That check is what catches the failure this issue is really about; the XML was a one-time demonstration.