Zip64 archive extraction broken in 8.8.0rc1: "Malformed Central Directory File Header" (regression from #30530)

[MichaelSbarraKodiak]

Description of the bug:

repository_ctx.download_and_extract (used by rules_python's pip.parse/whl_library, and any other repo rule extracting a .zip/.whl) fails to extract large (Zip64-format) archives with:

Error extracting <path> to <dir>: Malformed Central Directory File Header; does not start with <hash>

This is probably a regression introduced by #30530 ("Windows Zip fixes"), cherry-picked into release-8.8.0 as commit 7393bd2801 (original commits b12c06a2d5 / 10bcb4c1fe on master). Not present in Bazel 8.7.0.

Root cause:

ZipReader.readEntries() in src/java_tools/singlejar/java/com/google/devtools/build/zip/ZipReader.java was changed by #30530 to compute the central directory start as:

long actualCenEnd =
    (zipData.isZip64() && zipData.getZip64EndOfCentralDirectoryOffset() > 0)
        ? zipData.getZip64EndOfCentralDirectoryOffset()
        : eocdLocation;
long actualCenStart = actualCenEnd - zipData.getCentralDirectorySize();
...
readCentralDirectoryFileHeaders(zipData.getExpectedEntries(), actualCenStart);

Previously it used zipData.getCentralDirectoryOffset() (parsed directly from the Zip64 End of Central Directory record) unconditionally for Zip64 archives. The new SFX-offset-adjustment logic (added alongside AdjustSfx.java) computes a start
offset that, for at least some legitimate non-SFX Zip64 archives, disagrees with the parsed getCentralDirectoryOffset(). The reader then seeks to the wrong file offset, and the first bytes it reads there aren't the expected PK\x01\x02
(0x02014b50) signature.

Impact: Blocks upgrading to Bazel 8.8.0 for any project extracting large (>4GB-class) zip/whl archives via repository rules.

Which category does this issue belong to?

External Dependency

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Build any target that, via bzlmod + rules_python's (v1.4.0) pip.parse, depends on a large manylinux wheel that requires Zip64 (e.g. tensorrt_cu13_libs==10.13.3.9.post1, sha256 6d44834e..., a multi-GB wheel) under Bazel 8.8.0rc1. Extraction of the
corresponding whl_library repo fails during loading with the error above. The identical build succeeds under Bazel 8.7.0.

ERROR: loading failure: com.google.devtools.build.lib.rules.repository.RepositoryFunction$AlreadyReportedRepositoryAccessException:
java.io.IOException: Error extracting .../external/rules_python++pip+pip_310_tensorrt_cu13_libs_sdist_6d44834e/tensorrt_cu13_libs-10.13.3.9.post1-py2.py3-none-manylinux_228_x86_64.whl
to .../external/rules_python++pip+pip_310_tensorrt_cu13_libs_sdist_6d44834e:
Malformed Central Directory File Header; does not start with 02014b50

Which operating system are you running Bazel on?

Linux x86_64

What is the output of bazel info release?

release 8.8.0rc1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

N/A

What's the output of git remote get-url origin; git rev-parse HEAD ?

N/A

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

Already identified without needing to bisect: introduced by 7393bd2 ("[8.8.0] Windows Zip fixes (#30530)"), cherry-picked from original commits b12c06a / 10bcb4c on master. Not present in Bazel 8.7.0 (8.7.0rc2 and earlier).

Have you found anything relevant by searching the web?

N/A

Any other information, logs, or outputs that you want to share?

Ask: please verify #30530's Zip64 central-directory-offset handling against non-SFX Zip64 archives before 8.8.0 final, or gate the new actualCenEnd/actualCenStart path so it only applies when actually needed for SFX adjustment.

[fmeum]

@iancha1992 @Wyverald

[meteorcloudy]

/cc @ted-xie, I created a fix with Gemini #30685, please check if it makes sense

[ted-xie]

Thanks for filing this. It's quite unfortunate that we had to write a custom tool to do SFX adjustment (the SFX rewriting built into the zip tool seemed to be causing issues on Windows), and the custom tool is imperfect. The general goal of revisiting the SFX logic and workflow is on my TODO pile.