Harden PKIX load before production load/save use

[lodekeeper]

Parent tracker: ChainSafe/lodestar#9647
Origin: follow-up from the 2026-08-04 blst-z/lodestar-z audit comment on ChainSafe/lodestar#9647.

Problem

pkix.load / pkix.save are intended for an application-owned local cache snapshot, not operator-provided or cross-network input. The loader already checks framing, ABI compatibility, file size, capacity bounds, and checksum. Because the whole file is checksummed, restored affine points do not need separate semantic validation as long as the file remains inside that application-owned cache boundary.

This is acceptable while Lodestar does not call pubkeyCache.load/save today, and remains acceptable if future production use keeps the file under an application-owned, network-scoped cache path. Before wiring PKIX snapshots into production, the application should make that trust boundary explicit and avoid treating the file as generic user input.

Acceptance Criteria

• Document the production trust boundary as application-owned local cache only.
• Keep the current capacity/file-size bounds, and add tests that crafted headers cannot force excessive allocation.
• Add malformed/corrupt/checksum fixture coverage for the chosen behavior.
• Ensure the application owns network scoping for the cache path; no separate "wrong-network" PKIX fixture is required.
• Link the Lodestar PR/commit that first wires production load/save usage, if any.

Notes

This is not a current Lodestar #9728 blocker because Lodestar does not call pubkeyCache.load/save today. It is a gate before making PKIX snapshots part of a production startup path.

[wemeetagain]

• application-owned local cache only
• we don't need to validate restored affine points, the whole file is checksummed
• more tests? sure
• "wrong-network" fixture -- this is up to the application to not mess up. The same issues can be said of all application data 🤪

[lodekeeper]

Thanks, updated the issue body to match this scope.

Decision from this thread:

• Treat PKIX files as application-owned local cache only.
• No separate validation of restored affine points is required while the whole file is checksummed inside that cache boundary.
• Dropped the wrong-network fixture requirement; cache path/network scoping is the application's responsibility, same as other application-owned data.
• Kept the test follow-up for crafted headers / malformed or corrupt checksum fixtures.

No implementation patch from this notification; #539 remains a pre-production load/save gate plus test/documentation follow-up.

[spiral-ladder]

we don't need to validate restored affine points, the whole file is checksummed

@wemeetagain yeah, I had similar question (would we ever load an untrusted pkix file?) on the original issue, this hardening seems like nice-to-have but not a blocker

[wemeetagain]

Yeah we wouldn't eve load an untrusted pkix file. Like we wouldn't ever load an untrusted database or ENR or any of the other things that the application persists to disk.