feat(self-packaging #65): ZIP64-sentinel WARN log in bundle_locator#68
Merged
Conversation
When a ZIP exceeds 4 GiB or 65535 entries, the EOCD's cd_size / cd_offset / entry-count fields are pinned to 0xffffffff / 0xffff and the real values live in a ZIP64 EOCD record that we don't parse. The existing range-check rejection silently returned nullopt for these, making the failure indistinguishable from "no bundle present" in operator logs. - bundle_locator: explicit ZIP64 sentinel check inside the EOCD scan loop; on match, emit a single-line CROW_LOG_WARNING naming the mismatch + offending field values, and return nullopt - bundle_locator_test: rename the existing 0xffffffff fixture to call out the ZIP64 origin (issue #65); add a second case for the 16-bit entry-count sentinel (0xffff) that previously slipped past the range checks since cd_size/cd_offset can still be plausible
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to the narrowing comment on #65. The defensive rejection of
ZIP64-sentinel-shaped EOCDs was already in place via the implicit
range checks at `src/bundle_locator.cpp:89-94`, but the failure
returned `nullopt` with no log line -- indistinguishable from
"no bundle present" in operator output.
This PR makes the ZIP64 case explicit:
`cd_offset == 0xffffffff`, `entries_this == 0xffff`, or
`entries_total == 0xffff`) inside the EOCD scan loop, after the
disk-number sanity checks.
offending field values, so an operator who packed a > 4 GiB or
range-check rejection.
Full ZIP64 EOCD locator (`0x06064b50`) + ZIP64 EOCD record parsing is
deliberately not implemented -- config bundles will never approach
4 GiB, and the WARN log gives operators enough signal to act.
Changes
(other src/ files like `credential_manager.cpp` use the same
header for the same purpose).
fields" to "rejects ZIP64-sentinel cd_size / cd_offset
(issue ZIP64 read-side defensiveness in bundle_locator + archive_io #65)" and adds the `[zip64]` tag.
(issue ZIP64 read-side defensiveness in bundle_locator + archive_io #65)" exercising the 16-bit entry-count sentinel
(`0xffff`) with otherwise-plausible cd_size/cd_offset --
a case the existing range-check rejection would have missed.
namespace.
Test plan
tests; the new tag `[zip64]` picks up both ZIP64 cases)
Closes #65.