Port several downstream patches from rhel

Fixes for:
- RHEL-86228, RHEL-45997
- Some coverity issues
- CVE-2022-0529 and CVE-2022-0530 (thanks Stewart Smith for head up
  about these)

.fmf/version

@@ -0,0 +1 @@
+1

plans/all.fmf

@@ -0,0 +1,6 @@
+summary: Basic smoke test
+discover:
+    how: fmf
+    url: https://src.fedoraproject.org/tests/unzip.git
+execute:
+    how: tmt

unzip-6.0-CVE-2022-0529-and-0530.patch

@@ -0,0 +1,170 @@
+From: Steven M. Schweda <sms@antinode.info>
+Subject: Fix for CVE-2022-0529 and CVE-2022-0530
+Bug-Debian: https://bugs.debian.org/1010355
+X-Debian-version: 6.0-27
+
+--- a/fileio.c
++++ b/fileio.c
+@@ -171,8 +171,10 @@
+ static ZCONST char Far FilenameTooLongTrunc[] =
+   "warning:  filename too long--truncating.\n";
+ #ifdef UNICODE_SUPPORT
++   static ZCONST char Far UFilenameCorrupt[] =
++     "error: Unicode filename corrupt.\n";
+    static ZCONST char Far UFilenameTooLongTrunc[] =
+-     "warning:  Converted unicode filename too long--truncating.\n";
++     "warning:  Converted Unicode filename too long--truncating.\n";
+ #endif
+ static ZCONST char Far ExtraFieldTooLong[] =
+   "warning:  extra field too long (%d).  Ignoring...\n";
+@@ -2361,16 +2363,30 @@
+                   /* convert UTF-8 to local character set */
+                   fn = utf8_to_local_string(G.unipath_filename,
+                                             G.unicode_escape_all);
+-                  /* make sure filename is short enough */
+-                  if (strlen(fn) >= FILNAMSIZ) {
+-                    fn[FILNAMSIZ - 1] = '\0';
++
++                  /* 2022-07-22 SMS, et al.  CVE-2022-0530
++                   * Detect conversion failure, emit message.
++                   * Continue with unconverted name.
++                   */
++                  if (fn == NULL)
++                  {
+                     Info(slide, 0x401, ((char *)slide,
+-                      LoadFarString(UFilenameTooLongTrunc)));
+-                    error = PK_WARN;
++                     LoadFarString(UFilenameCorrupt)));
++                    error = PK_ERR;
++                  }
++                  else
++                  {
++                    /* make sure filename is short enough */
++                    if (strlen(fn) >= FILNAMSIZ) {
++                      fn[FILNAMSIZ - 1] = '\0';
++                      Info(slide, 0x401, ((char *)slide,
++                        LoadFarString(UFilenameTooLongTrunc)));
++                      error = PK_WARN;
++                    }
++                    /* replace filename with converted UTF-8 */
++                    strcpy(G.filename, fn);
++                    free(fn);
+                   }
+-                  /* replace filename with converted UTF-8 */
+-                  strcpy(G.filename, fn);
+-                  free(fn);
+                 }
+ # endif /* UNICODE_WCHAR */
+                 if (G.unipath_filename != G.filename_full)
+--- a/process.c
++++ b/process.c
+@@ -222,6 +222,8 @@
+      "\nwarning:  Unicode Path version > 1\n";
+    static ZCONST char Far UnicodeMismatchError[] =
+      "\nwarning:  Unicode Path checksum invalid\n";
++   static ZCONST char Far UFilenameTooLongTrunc[] =
++     "warning:  filename too long (P1) -- truncating.\n";
+ #endif
+ 
+ 
+@@ -1915,7 +1917,7 @@
+     Sets both local header and central header fields.  Not terribly clever,
+     but it means that this procedure is only called in one place.
+ 
+-    2014-12-05 SMS.
++    2014-12-05 SMS.  (oCERT.org report.)  CVE-2014-8141.
+     Added checks to ensure that enough data are available before calling
+     makeint64() or makelong().  Replaced various sizeof() values with
+     simple ("4" or "8") constants.  (The Zip64 structures do not depend
+@@ -1947,7 +1949,7 @@
+ 
+         if (eb_id == EF_PKSZ64)
+         {
+-          int offset = EB_HEADSIZE;
++          unsigned offset = EB_HEADSIZE;
+ 
+           if ((G.crec.ucsize == Z64FLGL) || (G.lrec.ucsize == Z64FLGL))
+           {
+@@ -2046,7 +2049,7 @@
+         }
+         if (eb_id == EF_UNIPATH) {
+ 
+-          int offset = EB_HEADSIZE;
++          unsigned offset = EB_HEADSIZE;
+           ush ULen = eb_len - 5;
+           ulg chksum = CRCVAL_INITIAL;
+ 
+@@ -2504,16 +2507,17 @@
+   int state_dependent;
+   int wsize = 0;
+   int max_bytes = MB_CUR_MAX;
+-  char buf[9];
++  char buf[ MB_CUR_MAX+ 1];             /* ("+1" not really needed?) */
+   char *buffer = NULL;
+   char *local_string = NULL;
++  size_t buffer_size;                   /* CVE-2022-0529 */
+ 
+   for (wsize = 0; wide_string[wsize]; wsize++) ;
+ 
+   if (max_bytes < MAX_ESCAPE_BYTES)
+     max_bytes = MAX_ESCAPE_BYTES;
+-
+-  if ((buffer = (char *)malloc(wsize * max_bytes + 1)) == NULL) {
++  buffer_size = wsize * max_bytes + 1;          /* Reused below. */
++  if ((buffer = (char *)malloc( buffer_size)) == NULL) {
+     return NULL;
+   }
+ 
+@@ -2551,8 +2555,28 @@
+     } else {
+       /* no MB for this wide */
+         /* use escape for wide character */
+-        char *escape_string = wide_to_escape_string(wide_string[i]);
+-        strcat(buffer, escape_string);
++        size_t buffer_len;
++        size_t escape_string_len;
++        char *escape_string;
++        int err_msg = 0;
++
++        escape_string = wide_to_escape_string(wide_string[i]);
++        buffer_len = strlen( buffer);
++        escape_string_len = strlen( escape_string);
++
++        /* Append escape string, as space allows. */
++        /* 2022-07-18 SMS, et al.  CVE-2022-0529 */
++        if (escape_string_len > buffer_size- buffer_len- 1)
++        {
++            escape_string_len = buffer_size- buffer_len- 1;
++            if (err_msg == 0)
++            {
++                err_msg = 1;
++                Info(slide, 0x401, ((char *)slide,
++                 LoadFarString( UFilenameTooLongTrunc)));
++            }
++        }
++        strncat( buffer, escape_string, escape_string_len);
+         free(escape_string);
+     }
+   }
+@@ -2604,9 +2628,18 @@
+   ZCONST char *utf8_string;
+   int escape_all;
+ {
+-  zwchar *wide = utf8_to_wide_string(utf8_string);
+-  char *loc = wide_to_local_string(wide, escape_all);
+-  free(wide);
++  zwchar *wide;
++  char *loc = NULL;
++
++  wide = utf8_to_wide_string( utf8_string);
++
++  /* 2022-07-25 SMS, et al.  CVE-2022-0530 */
++  if (wide != NULL)
++  {
++    loc = wide_to_local_string( wide, escape_all);
++    free( wide);
++  }
++
+   return loc;
+ }
+ 

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,

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  %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";
++  -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";
 +#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\
-+  -I CHARSET  specify a character encoding for UNIX and other archives\n\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";
  #else /* !VMS */
  static ZCONST char Far UnzipUsageLine4[] = "\
  modifiers:\n\

unzip-6.0-fix-warning-messages-on-big-files.patch

@@ -0,0 +1,15 @@
+From: "Steven M. Schweda" <sms@antinode.info>
+Subject: Fix lame code in fileio.c
+Bug-Debian: https://bugs.debian.org/929502
+X-Debian-version: 6.0-23
+
+--- a/fileio.c
++++ b/fileio.c
+@@ -2477,6 +2477,7 @@
+      */
+     return (((zusz_t)sig[7]) << 56)
+         + (((zusz_t)sig[6]) << 48)
++        + (((zusz_t)sig[5]) << 40)
+         + (((zusz_t)sig[4]) << 32)
+         + (zusz_t)((((ulg)sig[3]) << 24)
+                  + (((ulg)sig[2]) << 16)

unzip-6.0-sast.patch

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

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

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

@@ -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 ((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;

unzip-zipbomb-switch.patch

@@ -137,26 +137,13 @@ index 878817d..3e58071 100644
 -    if ((G.lrec.general_purpose_bit_flag & 8) != 0) {
 +    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)
-          */
-@@ -2189,16 +2196,16 @@ static int extract_or_test_member(__G)    /* return PK-type error code */
-               ((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 */
-+                /* if not SIG, have signature */
-                 )))))
--                   /* skip four more bytes to account for signature */
--                   shy += 4 - readbuf((char *)buf, 4);
-+          /* 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 */
-+          shy += 8 - readbuf((char *)buf, 8); /* skip eight more for ZIP64 */
-         if (shy)
--            error = PK_ERR;
-+          error = PK_ERR;
+         // 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.
+@@ -2189,8 +2196,8 @@ static int extract_or_test_member(__G)    /* return PK-type error code */
+             G.incnt += back;
+             G.inptr -= back;
+         }
 +      }
      }
 -

unzip.spec

@@ -6,8 +6,8 @@
 Summary: A utility for unpacking zip files
 Name: unzip
 Version: 6.0
-Release: 57%{?dist}
-License: BSD
+Release: 71%{?dist}
+License: Info-ZIP
 Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz
 
 # Not sent to upstream.
@@ -70,7 +70,19 @@ 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
+Patch33: unzip-zipbomb-part7.patch
+Patch34: unzip-zipbomb-switch.patch
+
+Patch35: unzip-gnu89-build.patch
+Patch36: unzip-6.0-wcstombs-fortify.patch
+
+Patch37: unzip-6.0-fix-warning-messages-on-big-files.patch
+Patch38: unzip-6.0-sast.patch
+Patch39: unzip-6.0-RHEL-86228.patch
+#From Debian
+Patch40: unzip-6.0-CVE-2022-0529-and-0530.patch
+
+
 
 URL: http://infozip.sourceforge.net
 BuildRequires: make
@@ -89,40 +101,47 @@ a zip archive.
 
 %prep
 %setup -q -n unzip60
-%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
+%patch -P1 -p1
+%patch -P2 -p1
+%patch -P3 -p1
+%patch -P4 -p1
+%patch -P5 -p1
+%patch -P6 -p1
+%patch -P7 -p1
+%patch -P8 -p1
+%patch -P9 -p1
+%patch -P10 -p1
+%patch -P11 -p1
+%patch -P12 -p1
+%patch -P13 -p1
+%patch -P14 -p1
+%patch -P15 -p1
+%patch -P16 -p1
+%patch -P17 -p1
+%patch -P18 -p1
+%patch -P19 -p1
+%patch -P20 -p1
+%patch -P21 -p1
+%patch -P22 -p1
+%patch -P23 -p1
+%patch -P24 -p1
+%patch -P25 -p1
 
-%patch26 -p1
-%patch27 -p1
-%patch28 -p1
-%patch29 -p1
-%patch30 -p1
-%patch31 -p1
-%patch32 -p1
-%patch33 -p1
+%patch -P26 -p1
+%patch -P27 -p1
+%patch -P28 -p1
+%patch -P29 -p1
+%patch -P30 -p1
+%patch -P31 -p1
+%patch -P32 -p1
+%patch -P33 -p1
+%patch -P34 -p1
+%patch -P35 -p1
+%patch -P36 -p1
+%patch -P37 -p1
+%patch -P38 -p1
+%patch -P39 -p1
+%patch -P40 -p1
 
 %build
 # IZ_HAVE_UXUIDGID is needed for right functionality of unzip -X
@@ -141,6 +160,57 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_
 %{_mandir}/*/*
 
 %changelog
+* Wed Jul 22 2026 Jakub Martisko <jamartis@redhat.com> - 6.0-71
+- Port some RHEL downstream patches to fedora
+- Fixes for RHEL-86228, RHEL-45997 + some issues found by coverity and other scans
+- Fixes for CVE-2022-0529 and 2022-0530 (Thanks Stewart Smith for the Heads up about these)
+
+* Fri Jul 17 2026 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-70
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_45_Mass_Rebuild
+
+* Sat Jan 17 2026 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-69
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild
+
+* Wed Aug 20 2025 Jakub Martisko <jamartis@redhat.com> - 6.0-68
+- Another zipmbomb patch
+Resolves: rhbz#2360938
+
+* Fri Jul 25 2025 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-67
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_43_Mass_Rebuild
+
+* Sun Jan 19 2025 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-66
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild
+
+* Mon Nov 25 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-65
+- Zipinfo: remove the extra %c that cause invalid reads
+- Zipinfo: fix the whitespace formating of the help message
+Related: RHEL-59972
+
+* Sat Jul 20 2024 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-64
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_41_Mass_Rebuild
+
+* Sat Jan 27 2024 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-63
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
+
+* Sat Jul 22 2023 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-62
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
+* Thu Apr 13 2023 Lukáš Zaoral <lzaoral@redhat.com> - 6.0-61
+- migrate to SPDX license format
+
+* Wed Jan 25 2023 Siddhesh Poyarekar <siddhesh@redhat.com> - 6.0-60
+- Fix length passed to wcstombs call (#2164068)
+
+* Sat Jan 21 2023 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-59
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
+
+* Wed Nov 09 2022 Jakub Martisko <jamartis@redhat.com> - 6.0-59
+- 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