[Security] Enforce streamed response caps and contract parity for remote catalogs and art

[rwang23]

[Security] Enforce streamed response caps and contract parity for remote catalogs and art

Draft status: ready to create; not submitted by the audit run.
Priority: P1
Findings: ACT-010, ACT-011, ACT-012

Summary

Remote Catalog, Registry, and PNG integrity checks are strong, but some code paths buffer complete HTTP response bodies before enforcing the actual byte limit. Node/JSON Schema/Rust validation also has contract drift, and the trust root remains same-origin without an independent signed release manifest.

中文摘要：远程资源有路径、字节、PNG 签名与 SHA-256 校验，这是优点；但部分路径在真正限流前先把响应完整读入内存。需要按 chunk 硬限制，同时建立 Node/Schema/Rust 契约一致性，并规划独立签名。

Audit evidence

• Catalog/Registry code uses complete-response .bytes() buffering in relevant paths.
• Full Skin art checks declared size/Content-Length, but a chunked or dishonest response may still be fully buffered before the actual accumulated size is rejected.
• Rust validation checks the runtime-required subset but does not share an exact invalid/valid fixture suite with the authoritative JSON Schema and Node validator.
• A nativeSha256 field is read from a Full Skin capture shape where it does not exist, leaving a persistent null mapping.
• Catalog and Registry hashes protect consistency but are delivered from the same publication origin; origin compromise can replace both the descriptor and the expected hash.

Proposed direction

1. Add a shared streaming downloader with hard per-artifact limits, total timeout, redirect policy, allowed content types, and incremental hashing.
2. Write to a temporary file/buffer only within the cap; validate actual bytes and SHA before atomic cache replacement.
3. Create shared contract fixtures consumed by JSON Schema, Node, and Rust tests.
4. Remove or correctly map fields that are not part of the Registry contract.
5. Add a design and migration path for an offline-signed release/catalog manifest with key rotation and rollback protection.

Acceptance criteria

• Catalog, Registry, PNG, and updater paths each have explicit hard byte limits enforced during streaming, not after full buffering.
• Tests cover missing Content-Length, chunked transfer, dishonest smaller/larger Content-Length, slow response, timeout, redirect, wrong media type, and exact-limit success.
• Cache replacement is atomic and retains the previous known-good file if download, validation, fsync, or rename fails.
• Node, JSON Schema, and Rust accept/reject the same shared fixture corpus for exact keys, paths, bytes, hashes, packages, captures, provenance, and revisions.
• The stale/incorrect nativeSha256 mapping is removed or mapped to an actual contract field with tests.
• The project documents whether and when Catalog/Registry will be independently signed, including key rotation and minimum-revision rollback protection.
• Security diagnostics are sanitized and do not expose local paths or private application data.

Related audit findings

ACT-010, ACT-011, ACT-012.

A capped-stream Rust reference is available in demo/rust/capped_download.rs in the audit bundle.

[rwang23]

The streamed limits, content-type/timeout checks, and atomic cache behavior landed in #26; the current Rust and source suites pass their covered cap, chunked-response, timeout, and cache-preservation cases.

The cross-language shared fixture corpus and the remaining Catalog/Registry signing and rollback-protection decision are not yet implemented. Keeping this Issue open rather than treating individual-language tests as contract parity.