import UBI unzip-6.0-48.el8_10

.gitignore

@@ -1 +1 @@
-unzip60.tar.gz
+SOURCES/unzip60.tar.gz

.unzip.metadata

@@ -0,0 +1 @@
+abf7de8a4018a983590ed6f5cbd990d4740f8a22 SOURCES/unzip60.tar.gz

SOURCES/unzip-6.0-COVSCAN-strcpy-with-overlapping-strings.patch

@@ -0,0 +1,34 @@
+From 8f6be666289211661906922cdfe6ea5a08c5b458 Mon Sep 17 00:00:00 2001
+From: Jakub Martisko <jamartis@redhat.com>
+Date: Tue, 13 Nov 2018 09:57:43 +0100
+Subject: [PATCH] envargs.c: strcpy with overlapping strings
+
+---
+ envargs.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/envargs.c b/envargs.c
+index f0a230d..daa3e47 100644
+--- a/envargs.c
++++ b/envargs.c
+@@ -31,6 +31,7 @@
+ #define __ENVARGS_C     /* identifies this source module */
+ #define UNZIP_INTERNAL
+ #include "unzip.h"
++#include <string.h>
+ 
+ #ifdef __EMX__          /* emx isspace() returns TRUE on extended ASCII !! */
+ #  define ISspace(c) ((c) & 0x80 ? 0 : isspace((unsigned)c))
+@@ -118,7 +119,8 @@ int envargs(Pargc, Pargv, envstr, envstr2)
+ 
+             /* remove escape characters */
+             while ((argstart = MBSCHR(argstart, '\\')) != (char *)NULL) {
+-                strcpy(argstart, argstart + 1);
++                //strcpy(argstart, argstart + 1);
++		memmove(argstart, argstart + 1,strlen(argstart + 1) + 1);
+                 if (*argstart)
+                     ++argstart;
+             }
+-- 
+2.14.5
+

SOURCES/unzip-6.0-RHEL-86228.patch

@@ -0,0 +1,19 @@
+From: Roy Tam
+Subject: Handle Microsoft ZIP64 files by ignoring invalid "Total number of disks" field
+Origin: https://sourceforge.net/p/infozip/bugs/42/
+Bug: https://sourceforge.net/p/infozip/bugs/42/
+Bug-Debian: https://bugs.debian.org/1064000
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/2051952
+X-Debian-version: 6.0-29
+
+--- a/process.c
++++ b/process.c
+@@ -1281,7 +1281,7 @@
+     fprintf(stdout,"\nnumber of disks (ECR) %u, (ECLOC64) %lu\n",
+             G.ecrec.number_this_disk, ecloc64_total_disks); fflush(stdout);
+ #endif
+-    if ((G.ecrec.number_this_disk != 0xFFFF) &&
++    if ((G.ecrec.number_this_disk != 0xFFFF) && ecloc64_total_disks &&
+         (G.ecrec.number_this_disk != ecloc64_total_disks - 1)) {
+       /* Note: For some unknown reason, the developers at PKWARE decided to
+          store the "zip64 total disks" value as a counter starting from 1,

SOURCES/unzip-6.0-alt-iconv-utf8.patch

@@ -174,11 +174,11 @@ Index: unzip-6.0/unzip.c
 +#else /* UNIX */
 +static ZCONST char Far ZipInfoUsageLine3[] = "miscellaneous options:\n\
 +  -h  print header line       -t  print totals for listed files or for all\n\
-+  -z  print zipfile comment   -T  print file times in sortable decimal format\
++  -z  print zipfile comment  %c-T%c print file times in sortable decimal format\
-+\n  -C  be case-insensitive   %s\
++\n %c-C%c be case-insensitive   %s\
 +  -x  exclude filenames that follow from listing\n\
-+  -O  CHARSET  specify a character encoding for DOS, Windows and OS/2 archives\n\
++  -O CHARSET  specify a character encoding for DOS, Windows and OS/2 archives\n\
-+  -I  CHARSET  specify a character encoding for UNIX and other archives\n";
++  -I CHARSET  specify a character encoding for UNIX and other archives\n";
 +#endif /* !UNIX */
  #ifdef MORE
     static ZCONST char Far ZipInfoUsageLine4[] =
@@ -196,8 +196,8 @@ Index: unzip-6.0/unzip.c
 +  -U  use escapes for all non-ASCII Unicode  -UU ignore any Unicode fields\n\
 +  -C  match filenames case-insensitively     -L  make (some) names \
 +lowercase\n %-42s  -V  retain VMS version numbers\n%s\
-+  -O  CHARSET  specify a character encoding for DOS, Windows and OS/2 archives\n\
++  -O CHARSET  specify a character encoding for DOS, Windows and OS/2 archives\n\
-+  -I  CHARSET  specify a character encoding for UNIX and other archives\n\n";
++  -I CHARSET  specify a character encoding for UNIX and other archives\n\n";
  #else /* !VMS */
  static ZCONST char Far UnzipUsageLine4[] = "\
  modifiers:\n\

SPECS/unzip.spec

@@ -1,3 +1,4 @@
+
 # Settings for EL <= 7
 %if 0%{?rhel} && 0%{?rhel} <= 7
 %{!?__global_ldflags: %global __global_ldflags -Wl,-z,relro}
@@ -6,8 +7,9 @@
 Summary: A utility for unpacking zip files
 Name: unzip
 Version: 6.0
-Release: 68%{?dist}
+Release: 48%{?dist}
-License: Info-ZIP
+License: BSD
+Group: Applications/Archiving
 Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz
 
 # Not sent to upstream.
@@ -57,32 +59,29 @@ Patch22: unzip-6.0-timestamp.patch
 
 # fix possible heap based stack overflow in passwd protected files
 Patch23: unzip-6.0-cve-2018-1000035-heap-based-overflow.patch
-
 Patch24: unzip-6.0-cve-2018-18384.patch
-
-# covscan issues
 Patch25: unzip-6.0-COVSCAN-fix-unterminated-string.patch
 
-Patch26: unzip-zipbomb-part1.patch
-Patch27: unzip-zipbomb-part2.patch
-Patch28: unzip-zipbomb-part3.patch
-Patch29: unzip-zipbomb-manpage.patch
-Patch30: unzip-zipbomb-part4.patch
-Patch31: unzip-zipbomb-part5.patch
-Patch32: unzip-zipbomb-part6.patch
-Patch33: unzip-zipbomb-switch.patch
-Patch34: unzip-gnu89-build.patch
-Patch35: unzip-6.0-wcstombs-fortify.patch
 
-#https://sources.debian.org/patches/unzip/6.0-28/21-fix-warning-messages-on-big-files.patch/
+Patch26: unzip-6.0-COVSCAN-strcpy-with-overlapping-strings.patch
-Patch36: unzip-6.0-fix-warning-messages-on-big-files.patch
 
-Patch37: unzip-zipbomb-part7.patch
+#zipbomb related patches (CVE-2019-13232)
-Patch38: unzip-6.0-sast.patch
+Patch27: unzip-zipbomb-part1.patch
+Patch28: unzip-zipbomb-part2.patch
+Patch29: unzip-zipbomb-part3.patch
+Patch30: unzip-zipbomb-manpage.patch
 
-URL: http://infozip.sourceforge.net
+Patch31: unzip-zipbomb-part4.patch
-BuildRequires: make
+Patch32: unzip-zipbomb-part5.patch
-BuildRequires:  bzip2-devel, gcc
+Patch33: unzip-zipbomb-part6.patch
+
+Patch34: unzip-zipbomb-switch.patch
+
+Patch35: unzip-6.0-fix-warning-messages-on-big-files.patch
+#https://sources.debian.org/src/unzip/6.0-29/debian/patches/29-handle-windows-zip64-files.patch/
+Patch36: unzip-6.0-RHEL-86228.patch
+URL: http://www.info-zip.org/UnZip.html
+BuildRequires:  bzip2-devel
 
 %description
 The unzip utility is used to list, test, or extract files from a zip
@@ -97,175 +96,109 @@ a zip archive.
 
 %prep
 %setup -q -n unzip60
-%patch1 -p1
+%patch1 -p1 -b .bzip2-configure
-%patch2 -p1
+%patch2 -p1 -b .exec-shield
-%patch3 -p1
+%patch3 -p1 -b .close
-%patch4 -p1
+%patch4 -p1 -b .attribs-overflow
-%patch5 -p1
+%patch5 -p1 -b .configure
-%patch6 -p1
+%patch6 -p1 -b .manpage-fix
-%patch7 -p1
+%patch7 -p1 -b .recmatch
-%patch8 -p1
+%patch8 -p1 -b .symlink
-%patch9 -p1
+%patch9 -p1 -b .caseinsensitive
-%patch10 -p1
+%patch10 -p1 -b .format-secure
-%patch11 -p1
+%patch11 -p1 -b .valgrind
-%patch12 -p1
+%patch12 -p1 -b .x-option
-%patch13 -p1
+%patch13 -p1 -b .overflow
-%patch14 -p1
+%patch14 -p1 -b .cve-2014-8139
-%patch15 -p1
+%patch15 -p1 -b .cve-2014-8140
-%patch16 -p1
+%patch16 -p1 -b .cve-2014-8141
-%patch17 -p1
+%patch17 -p1 -b .overflow-long-fsize
-%patch18 -p1
+%patch18 -p1 -b .heap-overflow-infloop
-%patch19 -p1
+%patch19 -p1 -b .utf
-%patch20 -p1
+%patch20 -p1 -b .utf-print
-%patch21 -p1
+%patch21 -p1 -b .cve-2016-9844
-%patch22 -p1
+%patch22 -p1 -b .timestamp
-%patch23 -p1
+%patch23 -p1 -b .cve-2018-1000035
-%patch24 -p1
+%patch24 -p1 -b .cve-2018-18384
-%patch25 -p1
 
-%patch26 -p1
+%patch25 -p1 -b .covscan1 
-%patch27 -p1
+%patch26 -p1 -b .covscan2
-%patch28 -p1
+
-%patch29 -p1
+%patch27 -p1 -b .zipbomb1
+%patch28 -p1 -b .zipbomb2
+%patch29 -p1 -b .zipbomb3
 %patch30 -p1
+
 %patch31 -p1
 %patch32 -p1
 %patch33 -p1
 %patch34 -p1
 %patch35 -p1
 %patch36 -p1
-%patch37 -p1
-%patch38 -p1
 
 %build
 # IZ_HAVE_UXUIDGID is needed for right functionality of unzip -X
-# NOMEMCPY solve problem with memory overlapping - decompression is slowly,
+# NOMEMCPY solve problem with memory overlapping - decomression is slowly,
 # but successfull.
-%make_build -f unix/Makefile CF_NOOPT="-I. -DUNIX $RPM_OPT_FLAGS -DNOMEMCPY -DIZ_HAVE_UXUIDGID -DNO_LCHMOD" \
+make -f unix/Makefile CF_NOOPT="-I. -DUNIX $RPM_OPT_FLAGS -DNOMEMCPY -DIZ_HAVE_UXUIDGID -DNO_LCHMOD" \
-                      LFLAGS2="%{?__global_ldflags}" generic_gcc
+                      LFLAGS2="%{?__global_ldflags}" generic_gcc %{?_smp_mflags}
 
 %install
-make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_mandir}/man1 INSTALL="cp -p" install
+rm -rf $RPM_BUILD_ROOT
+make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT/%{_mandir}/man1 INSTALL="cp -p" install
 
 %files
+%defattr(-,root,root)
 %license LICENSE COPYING.OLD
 %doc README BUGS
 %{_bindir}/*
 %{_mandir}/*/*
 
 %changelog
-* Tue Nov 26 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-68
+* Mon Apr 07 2025 Jakub Martisko <jamartis@redhat.com> - 6.0-48
-- Fix a sast issue (overlapping strcopy)
+- Allow decompression of some wrongly compressed files
-Resolves: RHEL-44659
+Resolves: RHEL-86231
 
-* Mon Nov 25 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-67
+* Wed Jul 03 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-47
-- zipinfo: remove the extra %c that caused invalid reads
-- zipinfo: fix the whitespaces in the output
-- Zipbombs: Port Another patch, orinally made by Mark Adler
-- https://github.com/madler/unzip/commit/af0d07f95809653b669d88aa0f424c6d5aa48ba0
-  Resolves: RHEL-59972
-  Resolves: RHEL-6286
-
-* Tue Oct 29 2024 Troy Dawson <tdawson@redhat.com> - 6.0-66
-- Bump release for October 2024 mass rebuild:
-  Resolves: RHEL-64018
-
-* Wed Jul 03 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-65
 - Fix: Unzip Fails on Large Zip Files
 - Use the patch from Debian dealing with this
-Resolves: RHEL-45993
+Resolves: RHEL-45997
 
-* Mon Jun 24 2024 Troy Dawson <tdawson@redhat.com> - 6.0-64
+* Thu Dec 16 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-46
-- Bump release for June 2024 mass rebuild
+- Add environment variable that disables the zipbomb detection
+- Resolves: rhbz#2020320
 
-* Sat Jan 27 2024 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-63
+* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-45
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
+Fix a false positive zipbomb detection
+Related: 1954649
+Related: 1953565
 
-* Sat Jul 22 2023 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-62
+* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-44
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+* Fix out of memory errors while checking for zip-bombs
+Resolves: #1900915
 
-* Thu Apr 13 2023 Lukáš Zaoral <lzaoral@redhat.com> - 6.0-61
+* Mon Nov 18 2019 Jakub Martisko <jamartis@redhat.com> - 6.0-43
-- migrate to SPDX license format
+- Update the man page with the new exit code introduced in 6.0-42
+- Related: CVE-2019-13232
 
-* Wed Jan 25 2023 Siddhesh Poyarekar <siddhesh@redhat.com> - 6.0-60
+* Thu Oct 17 2019 Jakub Martisko <jamartis@redhat.com> - 6.0-42
-- Fix length passed to wcstombs call (#2164068)
+- Fix CVE-2019-13232
+- Resolves: CVE-2019-13232
 
-* Sat Jan 21 2023 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-59
+* Wed Nov 14 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-41
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
+- Fix strcpy call with possibly overlapping src/dest strings.
+- Related: #1602721
 
-* Wed Nov 09 2022 Jakub Martisko <jamartis@redhat.com> - 6.0-59
+* Mon Nov 12 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-40
-- Rebuild with the -std=gnu89 flag
-Resolves: rhbz#1750694
-
-* Sat Jul 23 2022 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-58
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
-
-* Sat Jan 22 2022 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-57
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
-
-* Thu Dec 16 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-56
-- Update the manpage regarding the 6.0-55
-
-* Mon Dec 13 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-55
-- Allow to opt-out of the zipbomb detection
-
-* Tue Nov 09 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-54
-- Update the URL
-
-* Fri Jul 23 2021 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-53
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
-
-* Thu Apr 29 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-52
-- Sync the zipbomb false postives fixes with rhel
-- zipbomb-part4 patch introduced in 6.0-51 has been renamed to part6 and part4 and part5 have been ported from rhel
-Resolves: 1953565
-
-* Thu Mar 25 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-51
-- Fix false positive in the zipbomb detection
-Related: 1920632
-
-* Wed Jan 27 2021 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-50
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
-
-* Wed Jul 29 2020 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-49
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
-
-* Tue Jul 14 2020 Tom Stellard <tstellar@redhat.com> - 6.0-48
-- Use make macros
-- https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
-
-* Fri Jan 31 2020 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-47
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
-
-* Mon Nov 18 2019 Jakub Martisko <jamartis@redhat.com> - 6.0-46
-- Mention the zipbomb exit code in the manpage
-  Related: CVE-2019-13232
-
-* Wed Oct 23 2019 Jakub Martisko <jamartis@redhat.com> - 6.0-45
-- Fix possible zipbomb in unzip
-  Resolves: CVE-2019-13232
-
-* Sat Jul 27 2019 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-44
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
-
-* Sun Feb 03 2019 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-43
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
-
-* Thu Nov 08 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-42
 - fix several possibly unterminated strings
   When copying to OEM_CP and ISO_CP strings, the string could end unterminated
   (stncpy does not append '\0').
+- Related: #1602721
 
-* Thu Nov 08 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-41
+* Mon Nov 05 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-39
 - Fix CVE-2018-18384
   Resolves: CVE-2018-18384
 
-* Sat Jul 14 2018 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-40
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
-
-* Thu Mar 01 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-39
-- Add gcc to buildrequires
-
 * Tue Feb 13 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-38
 - Fix CVE-2018-1000035 - heap based buffer overflow when opening
   password protected files.

sources

@@ -1 +0,0 @@
-SHA512 (unzip60.tar.gz) = 0694e403ebc57b37218e00ec1a406cae5cc9c5b52b6798e0d4590840b6cdbf9ddc0d9471f67af783e960f8fa2e620394d51384257dca23d06bcd90224a80ce5d

unzip-6.0-sast.patch

@@ -1,11 +0,0 @@
---- a/envargs.c	2005-03-04 03:23:38.000000000 +0100
-+++ b/envargs.c	2024-11-26 13:17:22.289650230 +0100
-@@ -118,7 +118,7 @@
- 
-             /* remove escape characters */
-             while ((argstart = MBSCHR(argstart, '\\')) != (char *)NULL) {
--                strcpy(argstart, argstart + 1);
-+                memmove(argstart, argstart + 1, strlen(argstart + 1) + 1);
-                 if (*argstart)
-                     ++argstart;
-             }

unzip-6.0-wcstombs-fortify.patch

@@ -1,11 +0,0 @@
---- unzip60/extract.c	2023-01-25 07:05:58.742254870 -0500
-+++ unzip60.new/extract.c	2023-01-25 07:04:48.073435349 -0500
-@@ -2889,7 +2889,7 @@ char *fnfilter(raw, space, size)   /* co
-             strcpy( (char *)space, raw);
-             return (char *)space;
-         }
--        woslen = wcstombs( newraw, wostring, (woslen * MB_CUR_MAX) + 1);
-+        woslen = wcstombs( newraw, wostring, woslen + 1);
- 
-         if (size > 0) {
-             slim = space + size - 4;

unzip-gnu89-build.patch

@@ -1,15 +0,0 @@
-unzip uses C89-only features, so it needs to be built in C89 mode.
-
-diff --git a/unix/Makefile b/unix/Makefile
-index ab32270cf4b9b2cf..5eabbe13095e1f58 100644
---- a/unix/Makefile
-+++ b/unix/Makefile
-@@ -545,7 +545,7 @@ generic:	flags	   # now try autoconfigure first
- #	make $(MAKEF) unzips CF="${CF} `cat flags`"
- 
- generic_gcc:
--	$(MAKE) $(MAKEF) generic CC=gcc IZ_BZIP2="$(IZ_BZIP2)"
-+	$(MAKE) $(MAKEF) generic CC="gcc -std=gnu89" IZ_BZIP2="$(IZ_BZIP2)"
- 
- # extensions to perform SVR4 package-creation after compilation
- generic_pkg:	generic svr4package

unzip-zipbomb-part7.patch

@@ -1,172 +0,0 @@
-From af0d07f95809653b669d88aa0f424c6d5aa48ba0 Mon Sep 17 00:00:00 2001
-From: Mark Adler <fork@madler.net>
-Date: Sat, 2 Jul 2022 14:35:04 -0700
-Subject: [PATCH] Be more liberal in the acceptance of data descriptors.
-
-Previously the zip64 flag determined the size of the lengths in the
-data descriptor. This is compliant with the zip format. However, a
-bug in the Java zip library results in an incorrect setting of that
-flag. This commit permits either 32-bit or 64-bit lengths, auto-
-detecting which it is, which works around the Java bug.
----
- extract.c | 146 +++++++++++++++++++++++++++++++++++++++++++++---------
- 1 file changed, 123 insertions(+), 23 deletions(-)
-
-diff --git a/extract.c b/extract.c
-index 878817d..b1c74df 100644
---- a/extract.c
-+++ b/extract.c
-@@ -2173,30 +2173,130 @@ static int extract_or_test_member(__G)    /* return PK-type error code */
-     undefer_input(__G);
-     if (uO.zipbomb == TRUE) {
-       if ((G.lrec.general_purpose_bit_flag & 8) != 0) {
--        /* skip over data descriptor (harder than it sounds, due to signature
--         * ambiguity)
--         */
--#       define SIG 0x08074b50
--#       define LOW 0xffffffff
--        uch buf[12];
--        unsigned shy = 12 - readbuf((char *)buf, 12);
--        ulg crc = shy ? 0 : makelong(buf);
--        ulg clen = shy ? 0 : makelong(buf + 4);
--        ulg ulen = shy ? 0 : makelong(buf + 8); /* or high clen if ZIP64 */
--        if (crc == SIG &&                       /* if not SIG, no signature */
--            (G.lrec.crc32 != SIG ||             /* if not SIG, have signature */
--             (clen == SIG &&                    /* if not SIG, no signature */
--              ((G.lrec.csize & LOW) != SIG ||   /* if not SIG, have signature */
--               (ulen == SIG &&                  /* if not SIG, no signature */
--                (G.pInfo->zip64 ? G.lrec.csize >> 32 : G.lrec.ucsize) != SIG
--                /* if not SIG, have signature */
--                )))))
--          /* skip four more bytes to account for signature */
--          shy += 4 - readbuf((char *)buf, 4);
--        if (G.pInfo->zip64)
--          shy += 8 - readbuf((char *)buf, 8); /* skip eight more for ZIP64 */
--        if (shy)
-+        // Skip over the data descriptor. We need to correctly position the
-+        // read pointer after the data descriptor for the proper detection of
-+        // overlapped zip file components.
-+        //
-+        // We need to resolve an ambiguity over four possible data descriptor
-+        // formats. We check for all four, and pick the longest match. The data
-+        // descriptor can have a signature or not, and it can use four or
-+        // eight-byte lengths. The zip format requires resolving the ambiguity
-+        // of a signature or not, but it uses the zip64 flag to determine
-+        // whether the lengths are four or eight bytes. However there is a bug
-+        // in the Java zip library that applies the wrong value of that flag.
-+        // This works around that bug by always trying both length formats.
-+        //
-+        // So why the longest match? And does this resolve the ambiguity? No,
-+        // it doesn't definitively resolve the ambiguity. However choosing the
-+        // longest match at least resolves it for a normal zip file, where the
-+        // bytes following the data descriptor must be another zip signature
-+        // that is not a data descriptor signature. There are a few specific
-+        // cases for which more than one of the formats will match the given
-+        // CRC and lengths. The most plausible is between four and eight-byte
-+        // lengths, either with or without a signature. That only occurs for an
-+        // entry with an uncompressed size of zero. We consider the data
-+        // descriptor to be a vector of four-byte values. Then the possible
-+        // data descriptors are [(s) 0 c 0] and [(s) 0 c 0 0 0], where (s) is
-+        // the optional signature, and c is the compressed length. c would be
-+        // two for the Deflate compressed data format. These look the same, so
-+        // if the file contains [(s) 0 c 0 0 0], then we cannot discriminate
-+        // them. However if the data descriptor was intended to be [(s) 0 c 0],
-+        // then it has been followed by eight zero bytes in the zip file for
-+        // some reason. For a normal zip file this cannot be the case. The data
-+        // descriptor would always be immediately followed by another zip file
-+        // signature, which is four bytes that are not zeros. The other cases
-+        // where more than one format matches are vanishingly unlikely, but the
-+        // longest match strategy resolves those as well in a normal zip file.
-+        // Those pairs are [s s s] vs. [s s s s], [s s s] vs. [s s s 0 s 0],
-+        // and [s s s s s] vs. [s s s s s s]. For all, s is the signature for a
-+        // data descriptor. For the first two we have an entry whose CRC,
-+        // compressed length, and uncompressed length are all equal (!), and
-+        // are all equal to the signature (!!). If this occurs, clearly someone
-+        // is messing with us. However the strategy works nonetheless. We see
-+        // that if the shorter descriptor, [s s s] were what was intended, then
-+        // it has been followed by either four zero bytes or a data descriptor
-+        // signature. Neither can occur for a normal zip file, where it must be
-+        // followed by a signature that is not a data descriptor signature. So
-+        // the longest match is the correct choice. The final case is outright
-+        // insane, since the compressed and uncompressed lengths are the data
-+        // descriptor signature repeated twice to make a 64-bit length, which
-+        // is about 6e17. The largest drive available as I write this is 100TB,
-+        // which is one six thousandth of that length. If I apply Moore's law
-+        // to drive capacity, we might get to 6e17 about 25 years from now. If
-+        // this code is still in use then (I've seen other code I've written in
-+        // use for over 30 years), then we're still in luck. A data descriptor
-+        // cannot be followed by a data descriptor signature in a normal zip
-+        // file. The longest match strategy continues to work.
-+        //
-+        // So what is a not normal zip file, where these assumptions might fall
-+        // apart? zip files have been used in a non-standard way as a poor
-+        // substitute for a file system, with entries deleted and perhaps
-+        // others replacing them partially, with fragmented zip files being the
-+        // result. Then all bets are off as to what might or might not follow a
-+        // data descriptor. Though if this sort of data descriptor ambiguity
-+        // falls in one of those gaps, then there should be no adverse
-+        // consequences for picking the unintended one.
-+        int len = 0;
-+#       define SIG 0x08074b50           // optional data descriptor signature
-+#ifdef LARGE_FILE_SUPPORT
-+        uch buf[24];
-+        int got = readbuf((char *)buf, sizeof(buf));
-+        if (got >= 24 && makelong(buf) == SIG &&
-+                         makelong(buf + 4) == G.lrec.crc32 &&
-+                         makeint64(buf + 8) == G.lrec.csize &&
-+                         makeint64(buf + 16) == G.lrec.ucsize)
-+            // Have a data descriptor with a signature and 64-bit lengths.
-+            len = 24;
-+        else if (got >= 20 && makelong(buf) == G.lrec.crc32 &&
-+                              makeint64(buf + 4) == G.lrec.csize &&
-+                              makeint64(buf + 12) == G.lrec.ucsize)
-+            // Have a data descriptor with no signature and 64-bit lengths.
-+            len = 20;
-+        else if ((G.lrec.csize >> 32) == 0 && (G.lrec.ucsize >> 32) == 0)
-+            // Both lengths are short enough to fit in 32 bits.
-+#else
-+        uch buf[16];
-+        int got = readbuf((char *)buf, sizeof(buf));
-+#endif
-+        {
-+            if (got >= 16 && makelong(buf) == SIG &&
-+                             makelong(buf + 4) == G.lrec.crc32 &&
-+                             makelong(buf + 8) == G.lrec.csize &&
-+                             makelong(buf + 12) == G.lrec.ucsize)
-+                // Have a data descriptor with a signature and 32-bit lengths.
-+                len = 16;
-+            else if (got >= 12 && makelong(buf) == G.lrec.crc32 &&
-+                                  makelong(buf + 4) == G.lrec.csize &&
-+                                  makelong(buf + 8) == G.lrec.ucsize)
-+                // Have a data descriptor with no signature and 32-bit lengths.
-+                len = 12;
-+        }
-+        if (len == 0)
-+            // There is no data descriptor that matches the entry CRC and
-+            // length values.
-           error = PK_ERR;
-+
-+        // Back up got-len bytes, to position the read pointer after the data
-+        // descriptor. Or to where the data descriptor was supposed to be, in
-+        // the event none was found.
-+        int back = got - len;
-+        if (G.incnt + back > INBUFSIZ) {
-+            // Need to load the preceding buffer. We've been here before.
-+            G.cur_zipfile_bufstart -= INBUFSIZ;
-+#ifdef USE_STRM_INPUT
-+            zfseeko(G.zipfd, G.cur_zipfile_bufstart, SEEK_SET);
-+#else /* !USE_STRM_INPUT */
-+            zlseek(G.zipfd, G.cur_zipfile_bufstart, SEEK_SET);
-+#endif /* ?USE_STRM_INPUT */
-+            read(G.zipfd, (char *)G.inbuf, INBUFSIZ);
-+            G.incnt -= INBUFSIZ - back;
-+            G.inptr += INBUFSIZ - back;
-+        }
-+        else {
-+            // Back up within current buffer.
-+            G.incnt += back;
-+            G.inptr -= back;
-+        }
-       }
-     }
-     return error;