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

@@ -1,34 +0,0 @@
-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-alt-iconv-utf8.patch

@@ -174,8 +174,8 @@ 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  %c-T%c print file times in sortable decimal format\
-+\n %c-C%c be case-insensitive   %s\
++  -z  print zipfile comment   -T  print file times in sortable decimal format\n\
++  -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\
 +  -I CHARSET  specify a character encoding for UNIX and other archives\n";

SOURCES/unzip-zipbomb-part7.patch

@@ -0,0 +1,172 @@
+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;

SPECS/unzip.spec

@@ -7,9 +7,8 @@
 Summary: A utility for unpacking zip files
 Name: unzip
 Version: 6.0
-Release: 48%{?dist}
+Release: 60%{?dist}
 License: BSD
-Group: Applications/Archiving
 Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz
 
 # Not sent to upstream.
@@ -59,29 +58,30 @@ 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
 
-Patch26: unzip-6.0-COVSCAN-strcpy-with-overlapping-strings.patch
+Patch34: unzip-6.0-fix-warning-messages-on-big-files.patch
 
-#zipbomb related patches (CVE-2019-13232)
-Patch27: unzip-zipbomb-part1.patch
-Patch28: unzip-zipbomb-part2.patch
-Patch29: unzip-zipbomb-part3.patch
-Patch30: unzip-zipbomb-manpage.patch
-
-Patch31: unzip-zipbomb-part4.patch
-Patch32: unzip-zipbomb-part5.patch
-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
+Patch35: unzip-6.0-RHEL-86228.patch
+Patch36: unzip-zipbomb-part7.patch
+
 URL: http://www.info-zip.org/UnZip.html
-BuildRequires:  bzip2-devel
+BuildRequires: make
+BuildRequires:  bzip2-devel, gcc
 
 %description
 The unzip utility is used to list, test, or extract files from a zip
@@ -96,39 +96,37 @@ a zip archive.
 
 %prep
 %setup -q -n unzip60
-%patch1 -p1 -b .bzip2-configure
-%patch2 -p1 -b .exec-shield
-%patch3 -p1 -b .close
-%patch4 -p1 -b .attribs-overflow
-%patch5 -p1 -b .configure
-%patch6 -p1 -b .manpage-fix
-%patch7 -p1 -b .recmatch
-%patch8 -p1 -b .symlink
-%patch9 -p1 -b .caseinsensitive
-%patch10 -p1 -b .format-secure
-%patch11 -p1 -b .valgrind
-%patch12 -p1 -b .x-option
-%patch13 -p1 -b .overflow
-%patch14 -p1 -b .cve-2014-8139
-%patch15 -p1 -b .cve-2014-8140
-%patch16 -p1 -b .cve-2014-8141
-%patch17 -p1 -b .overflow-long-fsize
-%patch18 -p1 -b .heap-overflow-infloop
-%patch19 -p1 -b .utf
-%patch20 -p1 -b .utf-print
-%patch21 -p1 -b .cve-2016-9844
-%patch22 -p1 -b .timestamp
-%patch23 -p1 -b .cve-2018-1000035
-%patch24 -p1 -b .cve-2018-18384
+%patch1 -p1
+%patch2 -p1
+%patch3 -p1
+%patch4 -p1
+%patch5 -p1
+%patch6 -p1
+%patch7 -p1
+%patch8 -p1
+%patch9 -p1
+%patch10 -p1
+%patch11 -p1
+%patch12 -p1
+%patch13 -p1
+%patch14 -p1
+%patch15 -p1
+%patch16 -p1
+%patch17 -p1
+%patch18 -p1
+%patch19 -p1
+%patch20 -p1
+%patch21 -p1
+%patch22 -p1
+%patch23 -p1
+%patch24 -p1
+%patch25 -p1
 
-%patch25 -p1 -b .covscan1 
-%patch26 -p1 -b .covscan2
-
-%patch27 -p1 -b .zipbomb1
-%patch28 -p1 -b .zipbomb2
-%patch29 -p1 -b .zipbomb3
+%patch26 -p1
+%patch27 -p1
+%patch28 -p1
+%patch29 -p1
 %patch30 -p1
-
 %patch31 -p1
 %patch32 -p1
 %patch33 -p1
@@ -137,68 +135,109 @@ a zip archive.
 %patch36 -p1
 
 %build
+# Use the C implementation of CRC instead of assembly (only on i386, other architectures use C by default)
+sed -i -e 's:-DASM_CRC::g' unix/configure
+sed -i -e 's:CRC32OA="crc_gcc.o":CRC32OA="":g' unix/configure
+
 # IZ_HAVE_UXUIDGID is needed for right functionality of unzip -X
 # NOMEMCPY solve problem with memory overlapping - decomression is slowly,
 # but successfull.
-make -f unix/Makefile CF_NOOPT="-I. -DUNIX $RPM_OPT_FLAGS -DNOMEMCPY -DIZ_HAVE_UXUIDGID -DNO_LCHMOD" \
-                      LFLAGS2="%{?__global_ldflags}" generic_gcc %{?_smp_mflags}
+%make_build -f unix/Makefile CF_NOOPT="-I. -DUNIX $RPM_OPT_FLAGS -DNOMEMCPY -DIZ_HAVE_UXUIDGID -DNO_LCHMOD" \
+                      LFLAGS2="%{?__global_ldflags}" generic_gcc
 
 %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
-* Mon Apr 07 2025 Jakub Martisko <jamartis@redhat.com> - 6.0-48
-- Allow decompression of some wrongly compressed files
-Resolves: RHEL-86231
+* Fri Oct 10 2025 Jakub Martisko <jamartis@redhat.com> - 6.0-60
+- Another zipbomb patch (ported from c10s)
+Related: RHEL-6272
 
-* Wed Jul 03 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-47
+* Mon Apr 07 2025 Jakub Martisko <jamartis@redhat.com> - 6.0-59
+- Allow decompression of some wrongly compressed files
+Resolves: RHEL-86228
+
+* Tue Sep 24 2024 Matteo Croce <teknoraver@meta.com> - 6.0-58
+- Fix obscure invalid memory access in zipinfo
+Resolves: RHEL-60054
+
+* Wed Jul 03 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-57
 - Fix: Unzip Fails on Large Zip Files
 - Use the patch from Debian dealing with this
-Resolves: RHEL-45997
+Resolves: RHEL-45994
 
-* Thu Dec 16 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-46
-- Add environment variable that disables the zipbomb detection
-- Resolves: rhbz#2020320
+* Wed Jan 26 2022 Jakub Martisko <jamartis@redhat.com> - 6.0-56
+- Use the C crc implementation instead of the asm (i686 only, other arches already use C)
+Related: rhbz#2045075
 
-* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-45
-Fix a false positive zipbomb detection
-Related: 1954649
-Related: 1953565
+* Wed Jan 05 2022 Jakub Martisko <jamartis@redhat.com> - 6.0-55
+- Rebuild with the gating tests enabled
+Related: rhbz#2036946
 
-* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-44
-* Fix out of memory errors while checking for zip-bombs
-Resolves: #1900915
+* Mon Dec 20 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-54
+- Add an environment variable that disables the zipbomb detection
+  Resolves: rhbz#2031730
 
-* Mon Nov 18 2019 Jakub Martisko <jamartis@redhat.com> - 6.0-43
-- Update the man page with the new exit code introduced in 6.0-42
-- Related: CVE-2019-13232
+* Tue Aug 10 2021 Mohan Boddu <mboddu@redhat.com> - 6.0-53
+- Rebuilt for IMA sigs, glibc 2.34, aarch64 flags
+  Related: rhbz#1991688
 
-* Thu Oct 17 2019 Jakub Martisko <jamartis@redhat.com> - 6.0-42
-- Fix CVE-2019-13232
-- Resolves: CVE-2019-13232
+* Fri Apr 30 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-52
+- Add several patches dealing with false positice zipbomb detection
+Resolves: #1954651
 
-* Wed Nov 14 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-41
-- Fix strcpy call with possibly overlapping src/dest strings.
-- Related: #1602721
+* Fri Apr 16 2021 Mohan Boddu <mboddu@redhat.com> - 6.0-51
+- Rebuilt for RHEL 9 BETA on Apr 15th 2021. Related: rhbz#1947937
 
-* Mon Nov 12 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-40
+* 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
 
-* Mon Nov 05 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-39
+* Thu Nov 08 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-41
 - 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.