import CS unzip-6.0-68.el10

.gitignore

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

.unzip.metadata

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

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

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

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\
++  -z  print zipfile comment   -T  print file times in sortable decimal format\
-+\n %c-C%c be case-insensitive   %s\
++\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\
++  -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\

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

unzip.spec

@@ -1,4 +1,3 @@
-
 # Settings for EL <= 7
 %if 0%{?rhel} && 0%{?rhel} <= 7
 %{!?__global_ldflags: %global __global_ldflags -Wl,-z,relro}
@@ -7,9 +6,8 @@
 Summary: A utility for unpacking zip files
 Name: unzip
 Version: 6.0
-Release: 47%{?dist}
+Release: 68%{?dist}
-License: BSD
+License: Info-ZIP
-Group: Applications/Archiving
 Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz
 
 # Not sent to upstream.
@@ -59,27 +57,32 @@ 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
 
-Patch26: unzip-6.0-COVSCAN-strcpy-with-overlapping-strings.patch
+#https://sources.debian.org/patches/unzip/6.0-28/21-fix-warning-messages-on-big-files.patch/
+Patch36: unzip-6.0-fix-warning-messages-on-big-files.patch
 
-#zipbomb related patches (CVE-2019-13232)
+Patch37: unzip-zipbomb-part7.patch
-Patch27: unzip-zipbomb-part1.patch
+Patch38: unzip-6.0-sast.patch
-Patch28: unzip-zipbomb-part2.patch
-Patch29: unzip-zipbomb-part3.patch
-Patch30: unzip-zipbomb-manpage.patch
 
-Patch31: unzip-zipbomb-part4.patch
+URL: http://infozip.sourceforge.net
-Patch32: unzip-zipbomb-part5.patch
+BuildRequires: make
-Patch33: unzip-zipbomb-part6.patch
+BuildRequires:  bzip2-devel, gcc
-
-Patch34: unzip-zipbomb-switch.patch
-
-Patch35: unzip-6.0-fix-warning-messages-on-big-files.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
@@ -94,104 +97,175 @@ a zip archive.
 
 %prep
 %setup -q -n unzip60
-%patch1 -p1 -b .bzip2-configure
+%patch1 -p1
-%patch2 -p1 -b .exec-shield
+%patch2 -p1
-%patch3 -p1 -b .close
+%patch3 -p1
-%patch4 -p1 -b .attribs-overflow
+%patch4 -p1
-%patch5 -p1 -b .configure
+%patch5 -p1
-%patch6 -p1 -b .manpage-fix
+%patch6 -p1
-%patch7 -p1 -b .recmatch
+%patch7 -p1
-%patch8 -p1 -b .symlink
+%patch8 -p1
-%patch9 -p1 -b .caseinsensitive
+%patch9 -p1
-%patch10 -p1 -b .format-secure
+%patch10 -p1
-%patch11 -p1 -b .valgrind
+%patch11 -p1
-%patch12 -p1 -b .x-option
+%patch12 -p1
-%patch13 -p1 -b .overflow
+%patch13 -p1
-%patch14 -p1 -b .cve-2014-8139
+%patch14 -p1
-%patch15 -p1 -b .cve-2014-8140
+%patch15 -p1
-%patch16 -p1 -b .cve-2014-8141
+%patch16 -p1
-%patch17 -p1 -b .overflow-long-fsize
+%patch17 -p1
-%patch18 -p1 -b .heap-overflow-infloop
+%patch18 -p1
-%patch19 -p1 -b .utf
+%patch19 -p1
-%patch20 -p1 -b .utf-print
+%patch20 -p1
-%patch21 -p1 -b .cve-2016-9844
+%patch21 -p1
-%patch22 -p1 -b .timestamp
+%patch22 -p1
-%patch23 -p1 -b .cve-2018-1000035
+%patch23 -p1
-%patch24 -p1 -b .cve-2018-18384
+%patch24 -p1
+%patch25 -p1
 
-%patch25 -p1 -b .covscan1 
+%patch26 -p1
-%patch26 -p1 -b .covscan2
+%patch27 -p1
-
+%patch28 -p1
-%patch27 -p1 -b .zipbomb1
+%patch29 -p1
-%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 - decomression is slowly,
+# NOMEMCPY solve problem with memory overlapping - decompression is slowly,
 # but successfull.
-make -f unix/Makefile CF_NOOPT="-I. -DUNIX $RPM_OPT_FLAGS -DNOMEMCPY -DIZ_HAVE_UXUIDGID -DNO_LCHMOD" \
+%make_build -f unix/Makefile CF_NOOPT="-I. -DUNIX $RPM_OPT_FLAGS -DNOMEMCPY -DIZ_HAVE_UXUIDGID -DNO_LCHMOD" \
-                      LFLAGS2="%{?__global_ldflags}" generic_gcc %{?_smp_mflags}
+                      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
-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
-* Wed Jul 03 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-47
+* Tue Nov 26 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-68
+- Fix a sast issue (overlapping strcopy)
+Resolves: RHEL-44659
+
+* Mon Nov 25 2024 Jakub Martisko <jamartis@redhat.com> - 6.0-67
+- 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-45997
+Resolves: RHEL-45993
 
-* Thu Dec 16 2021 Jakub Martisko <jamartis@redhat.com> - 6.0-46
+* Mon Jun 24 2024 Troy Dawson <tdawson@redhat.com> - 6.0-64
-- Add environment variable that disables the zipbomb detection
+- Bump release for June 2024 mass rebuild
-- Resolves: rhbz#2020320
 
-* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-45
+* Sat Jan 27 2024 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-63
-Fix a false positive zipbomb detection
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
-Related: 1954649
-Related: 1953565
 
-* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-44
+* Sat Jul 22 2023 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-62
-* Fix out of memory errors while checking for zip-bombs
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
-Resolves: #1900915
 
-* Mon Nov 18 2019 Jakub Martisko <jamartis@redhat.com> - 6.0-43
+* Thu Apr 13 2023 Lukáš Zaoral <lzaoral@redhat.com> - 6.0-61
-- Update the man page with the new exit code introduced in 6.0-42
+- migrate to SPDX license format
-- Related: CVE-2019-13232
 
-* Thu Oct 17 2019 Jakub Martisko <jamartis@redhat.com> - 6.0-42
+* Wed Jan 25 2023 Siddhesh Poyarekar <siddhesh@redhat.com> - 6.0-60
-- Fix CVE-2019-13232
+- Fix length passed to wcstombs call (#2164068)
-- Resolves: CVE-2019-13232
 
-* Wed Nov 14 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-41
+* Sat Jan 21 2023 Fedora Release Engineering <releng@fedoraproject.org> - 6.0-59
-- Fix strcpy call with possibly overlapping src/dest strings.
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
-- Related: #1602721
 
-* Mon Nov 12 2018 Jakub Martisko <jamartis@redhat.com> - 6.0-40
+* 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
+
+* 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
 
-* 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.