On Fri, Jul 19, 2019 at 08:30:32AM +0900, Mike Hommey wrote: > Download > http://ftp.mozilla.org/pub/firefox/releases/68.0.1/linux-x86_64/en-US/firefox-68.0.1.tar.bz2 > Extract it > Unzip omni.ja > > The file *is* funky, but afaik it does not have overlapping components.
I think I know what's going on here--the Firefox omni.ja file uses an unusual zip layout, specific to Firefox, that puts the central directory at the *beginning* of the file, rather than the end. This is meant to allow for better disk caching when unpacking omni.ja, or something. https://bugzilla.mozilla.org/show_bug.cgi?id=559961 https://bugzilla.mozilla.org/show_bug.cgi?id=589368 You can see in this code sample, first Firefox looks for the central directory at offset 4, then falls back to the usual EOCD search. https://hg.mozilla.org/mozilla-central/file/af29567ecdba/modules/libjar/nsZipArchive.cpp#l597 https://hg.mozilla.org/mozilla-central/file/af29567ecdba/modules/libjar/nsZipArchive.cpp#l638 You can see this in the output of "zipinfo" as well; the central directory is at offset 4, and it shows warning relating to the unusual layout. (I'm using zipinfo 6.0-21+deb9u1 from Buster, which hasn't been patched yet.) $ zipinfo -v /usr/lib/firefox-esr/omni.ja The central directory is 111932 (000000000001B53Ch) bytes long, and its (expected) offset in bytes from the beginning of the zipfile is 4 (0000000000000004h). warning [/usr/lib/firefox-esr/omni.ja]: 16789751 extra bytes at beginning or within zipfile (attempting to process anyway) error [/usr/lib/firefox-esr/omni.ja]: reported length of central directory is -16789751 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1 zipfile?). Compensating... The unzip patch starts by initializing a cover that extends from the beginning of the central directory to the end of the file. In the case of the Firefox layout, that's the *entire* file, except for the first 4 bytes. So while none of the file overlap each other, they all appear to overlap the central directory. https://github.com/madler/unzip/commit/47b3ceae397d21bf822bc2ac73052a4b1daf8e1c#diff-42593f5e58d2da2cb6b6a937a04e16ddR496 The Firefox layout has also caused problems with 7-Zip: https://sourceforge.net/tracker/?func=detail&aid=3065694&group_id=14481&atid=114481 One possible solution is to adjust the bomb-cover patch so it only covers the actual length of the central directory (and the EOCD) separately. In almost all normal zip files, these two structures will be adjacent, so the effect will be the same as now.
