fix(sdk): fail fast when a TDF manifest would exceed the read-side size cap (DSPX-4651) - #1019
fix(sdk): fail fast when a TDF manifest would exceed the read-side size cap (DSPX-4651)#1019dmihalcik-virtru wants to merge 1 commit into
Conversation
…ze cap Extracts the 10MB manifest size check shared by write and read into assertManifestWithinSizeLimit (lib/tdf3/src/utils/zip-reader.ts) and calls it from writeStream before the manifest is emitted, so an oversized manifest (e.g. from a very large file at a small segment size) fails at encrypt time with an actionable ConfigurationError instead of producing a TDF that is permanently unreadable. Also fixes a >> 10 bitwise truncation bug in the existing read-side error message for manifests >= 4GiB. This is the first piece of DSPX-4651. The check still runs after the whole payload has been encrypted; making it an up-front estimate, and raising the cap so a 50 TiB file can fit under it at all, is the rest of that sub-task. DSPX-4651
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
1 participant
What
MANIFEST_MAX_SIZE(10 MB) was enforced only on the read path. This extracts the check into a sharedassertManifestWithinSizeLimit()inlib/tdf3/src/utils/zip-reader.tsand calls it fromwriteStream()before the manifest is emitted.Also fixes a
>> 10bitwise truncation in the read-side error message: for manifests ≥ 4 GiB the shift wraps and reports a nonsense size. NowMath.floor(n / 1024).Why
Today it is possible to encrypt a large file successfully and produce a TDF that no reader can ever open. The write path had no opinion about manifest size; the read path rejects at 10 MB. A 5 GB file at the default 1 MiB segment size produces ~5,000 segments and is fine, but the failure mode scales in silently — and the whole point of the 50 TiB work (DSPX-4648) is that the manifest is the binding constraint, not the payload.
Failing at encrypt time turns a permanent data-loss-shaped bug into an actionable
ConfigurationErrorthat names the segment count and tells the caller to raisesegmentSize.Scope / what this does not do
This is the first of two pieces of DSPX-4651. The check still runs after the entire payload has been encrypted, so it wastes the whole encrypt before rejecting. Making it an up-front estimate from the source size, and raising the cap so 50 TiB can fit under it at all, is the rest of the sub-task and lands separately.
How to test
New cases in
lib/tests/mocha/unit/zip.spec.tscover the boundary (at the limit passes, one byte over throws) and the ≥ 4 GiB message formatting.Risk
Low, but it is a new rejection on the write path: a caller who was previously writing an unreadable TDF now gets an error instead. That is the intent. No existing test produces a manifest anywhere near 10 MB.