Remove the 10 MB default manifest cap from the SDK reader
(defaultMaxManifestSize) and zipstream (manifestMaxSize). A 50 TiB payload,
the DSPX-4502 target, carries a manifest of more than 1 GiB, so no fixed
default can serve it. A declared manifest size is already bounded by the
archive itself in NewReader, so forged ZIP sizes are rejected without a cap.
WithMaxManifestSize remains as an opt-in memory bound and must be > 0.
Internally a non-positive zipstream limit means unlimited.
Signed-off-by: Dave Mihalcik <dmihalcik@virtru.com>
Summary
defaultMaxManifestSize) and from zipstream (manifestMaxSize).NewReaderalready checks every declared size and offset against the archive bounds (DSPX-4590, fix(sdk): bound zip64 reader offsets against the archive (DSPX-4590) #4043).WithMaxManifestSize(n)stays as an opt-in memory bound;nmust be > 0.WithTDFManifestMaxSizetreats a non-positive size as no cap.Behaviour change
LoadTDFandIsValidTdfnow accept manifests over 10 MB by default. Callers that relied on the old default to bound memory on untrusted input should passWithMaxManifestSize. Memory scaling of very large manifests is tracked separately in DSPX-4905.Testing
Test_LargeManifest_WithMaxManifest: an 11 MB manifest loads with default options; an explicit limit still rejects larger ones;WithMaxManifestSize(0)is an error.TestIsValidTdf_NoDefaultManifestSizeCapand new zipstreamTDFReadertests cover the default and opt-in paths.go test ./...insdkandsdk/internal/zipstream;golangci-lint run ./...insdkshows no findings in touched files. Rootmake lintandmake testnot yet run.Split out of the DSPX-5102 hardening work; independent of #4212.
Summary by CodeRabbit