fix(sdk): DSPX-4589 zip64 EOCD sentinels, truncated archive detection, and UTF-8 entry names

[dmihalcik-virtru]

Jira: https://virtru.atlassian.net/browse/DSPX-4589

Stack — this is 2 of 2. Split out of #396.

	PR	contents
1	#397 (base main)	per-segment size defaults
2	this PR (base #397)	zip64 EOCD sentinels, truncated archive detection, UTF-8 entry names
—	#396 (base main)	the combined diff of 1 + 2, as originally opened

Review the "Files changed" tab against the #397 base; GitHub will show only the zip changes.

Three zip container conformance findings from the audit against PKWARE APPNOTE.TXT. Each was written against pre-#393 main and re-verified against current main (98c839e2) before being changed; the honest status of each is below. None of the three has field impact — the one that did is #397.

Finding 1 — end of central directory sentinel thresholds (fixed)

ZipWriter.finish() decided whether the archive needed a zip64 end of central directory record with:

(numEntries & ~0xFF) != 0 || (startOfCentralDirectory & ~0xFFFF) != 0 || (sizeOfCentralDirectory & ~0xFFFF) != 0

None of those masks match the real field widths. The entry count field is 2 bytes, not 1, and the central directory offset and size fields are 4 bytes each, not 2. The practical effect was that any archive with 256 or more entries was needlessly promoted to zip64, and the offset/size checks fired three orders of magnitude too early.

Now:

var isZip64 = hasZip64Entry
        || numEntries > MAX_NON_ZIP64_ENTRY_COUNT          // 0xFFFE; 0xFFFF is the sentinel itself
        || needsZip64(startOfCentralDirectory, sizeOfCentralDirectory);

The offset and size go through needsZip64, so they honor the same deliberate 2 GiB (Integer.MAX_VALUE) ceiling as the per-entry fields — released readers widen these unsigned wire fields with signed reads, so we never write a value that would come back negative. Using needsZip64 also keeps the ZipWriter(out, maxNonZip64Value) test seam that #393 added usable for these two fields.

Not touched by #393 — verified with jj diff -r 98c839e2.

Finding 2 — truncated archive detection (fixed, but the branch was latent)

ZipReader.readEndOfCentralDirectory() scanned backwards for the EOCD signature and treated a null from readInteger() (a short read) as if it were a signature match, so a truncated archive could fall out of the loop and parse whatever bytes followed as an EOCD record. It now only breaks on a genuine match and throws InvalidZipException if the scan runs off the front, and separately rejects an archive too small to hold the zip64 locator its EOCD claims to have.

Stated plainly: with the SeekableInMemoryByteChannel the SDK actually uses, the scan position is always <= size - 22, so readInteger() always had four bytes available and the null branch was unreachable. This is a correctness/robustness fix (a FileChannel could in principle short-read), not a bug anyone was hitting. The new tests still pass on unpatched code for the plain-truncation cases; they are there to lock the behavior in.

Finding 3 — UTF-8 filename length (already correct on the wire; dead code removed)

The ticket says the central directory filename length was computed from String.length(). That assignment did exist:

cdFileHeader.filenameLength = (short) fileInfo.filename.length();

but CDFileHeader.write() never read the field — it wrote (short) filename.length from the already-encoded byte array. The bytes on the wire were already correct. No archive was ever mis-written.

What changed: the misleading dead filenameLength field is removed from both LocalFileHeader and CDFileHeader, the name is encoded to UTF-8 once instead of twice, and a new encodeFilename helper rejects a name whose encoded length exceeds 0xFFFF with an SDKException rather than silently truncating it into the 2-byte field.

Tests

7 new tests:

• ZipWriterTest — one test per EOCD sentinel driver: entry count (0xFFFE non-zip64 vs 0xFFFF zip64, round-tripped through ZipReader), central directory offset, and central directory size, each isolated so only the EOCD is zip64 and no entry is; plus filenameLengthIsMeasuredInUtf8Bytes ("🔒両.txt", String.length() 7 vs 11 UTF-8 bytes, asserted at both header offsets) and rejectsAnEntryNameTooLongToDescribe.
• ZipReaderTest — testTruncatedArchiveIsRejected (four truncation shapes) and testArchiveTooShortForTheZip64LocatorIsRejected, both asserting InvalidZipException.

The sentinel tests were confirmed to be genuine regression tests by reverting the EOCD mask fix and watching them fail.

mvn --batch-mode verify -Dmaven.antrun.skip -P 'coverage,non-fips,!fips'
  -> 242 tests, 0 failures, 0 errors, 8 skipped (235 at the #397 base)  [JDK 21]

End-to-end validation

None of these three findings has an xtest cell of its own — they are unit-tested only. What the e2e runs give this PR is a no-regression signal: xtest against this branch (which is also #396's head, i.e. the whole stack) is green, including the chunky cells that #397 fixes.

opentdf/tests run 34357326964 ✅ — java-ref=DSPX-4589-02-zip-format, force-supports=chunky, on the DSPX-4592-02-chunky branch. Java job: 82 passed, 22 skipped, no failures. All five java test_chunky_roundtrip pairs PASSED, none skipped.

The fix-vs-control comparison that proves #397 actually does something lives in #397.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}