fixing: CVE-2017-5974 CVE-2017-5975 CVE-2017-5976 CVE-2017-5978 CVE-2017-5981
Upstream changelog:
2017-04-24 guidod <guidod@gmx.de>
* common frontend 'unzzip.c' for example code in unzzip*-xx.c
* expand testcases to cover all of big/mem/mix/zap variants
* release v0.13.66
2017-04-23 guidod <guidod@gmx.de>
* turn the testsuite from makefile into python unittest format
* extend 'make check' testsuite to cover non-libzzip extensions
* fix unzzipcat-seeko and unzzipcat-mem to match the testsuite
* release v0.13.65
2017-04-20 guidod <guidod@gmx.de>
* check patches in opensuse builds, mostly for some CVE reports
2012-09-15 guidod <guidod@gmx.de>
* zzip.h, plugin.h: "};" at end of extern-C produces build errors with
the default --pedantic-errors on newer CMake. Thanks to Keith Thompson
recognizing it - see http://stackoverflow.com/questions/12384280/
2012-03-11 guidod <guidod@gmx.de>
* configure.ac: fallback to libtool -export-dynamic unless being sure to
use gnu-ld --export-dynamic. The darwin case is a bit special here
as the c-compiler and linker might be from different worlds.
* next 0.13.62 - needs a fix for mingw
(-mconsole is not a linker option, only the gcc should see it)
2010-12-30 guidod <guidod@gmx.de>
* done 0.13.60 release, tagged, and announced.
* prepare 0.13.61
2010-12-29 guidod <guidod@gmx.de>
* Makefile.am: allow nonstaic build
* wrap fd.open like in the Fedora patch
2010-12-28 guidod <guidod@gmx.de>
* zziplib.spec - simplify the spec based on distro specs.
2010-12-27 guidod <guidod@gmx.de>
* adding fetch.h/fetch.c to msvc8/zziplib.vcproj to allow
tests with Visual Studio C++ Express 2005
2010-12-27 guidod <guidod@gmx.de>
* fix stat.c to check ZZIP_CASELESS instead of the deprecated
ZZIP_CASEINSENSITIVE. The latter is still recognized for
compatibility reasons and implicitly mapped to ZZIP_CASELESS.
* fixes the zziplib-Patches-3078188 which reported the bug.
2010-12-27 guidod <guidod@gmx.de>
* apply patches by Peter Breitenlohner for better compatibility
with AIX host system. Also the Sun Studio compiler insists on
static inline functions or else assumes extern inline.
* also fixes zziplib-Patches-3011551 on the AIX problem.
2010-12-27 guidod <guidod@gmx.de>
* add hints that the ext_io plugin handlers should be static.
2010-05-09 guidod <guidod@gmx.de>
* zzip/__fnmatch.h: add include <string.h> to make mingw32 happy.
Patches item #2995373 by Gregory Smith
2010-05-08 guidod <guidod@gmx.de>
* SDL/Makefile.am: fix generation of sdl-uninstalled.pc that was
not recognized during compilation.
2010-04-05 guidod <guidod@gmx.de>
* Makefile.am: fix "osc rm" and fix "test-sdl" if SDL was not found.
* configure.ac: SDL example builds on pkgconfig/sdl.pc which
was introduced with SDL 1.2.11 - CentOs5 ships 1.2.10 which
does only have "sdl-config" and it made for a mismatch in
in the build configuration: sdl-devel yes, pkgconfig sdl no.
* zzip/zip.c (__zzip_parse_root_directory): move the check for
zzip_disk_entry_check_magic to be after the the check that
the seek-value is more than a header's size before the end.
(based on a segfault report by Tulipánt Gergely when the
new modulo_entries code is enabled (which is off by default))
2010-03-30 guidod <guidod@gmx.de>
* zzip/Makefile.am: fixing symlinks for lib* - use only for Linux
Thanks to Ryan Schmidt (macports):
... likes to install some symlinks that don't make sense on Mac OS X:
$ ls -l /opt/local/lib/*zzip*so*
lrwxr-xr-x /opt/local/lib/libzzip*.so.10 -> libzzip*.so.13
lrwxr-xr-x /opt/local/lib/libzzip*.so.11 -> libzzip*.so.13
lrwxr-xr-x /opt/local/lib/libzzip*.so.12 -> libzzip*.so.13
Yes, the filenames literally contain an asterisk.
Problems found with existing distfile for eagle:
distfiles/bicom101.zip
distfiles/szip-2.1nb3/szip-2.1.tar.gz
distfiles/xmill-0.9.1.tar.gz
No changes made to these distinfo files.
Otherwise, existing SHA1 digests verified and found to be the same on
the machine holding the existing distfiles (morden). All existing
SHA1 digests retained for now as an audit trail.
Major change since 0.10.x:
There were some problematic zip files out there that can trigger
segfaults in 0.10.x. Later zzip file decoders have extra checks and
helper routines for that.
This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.
and add a new helper target and script, "show-buildlink3", that outputs
a listing of the buildlink3.mk files included as well as the depth at
which they are included.
For example, "make show-buildlink3" in fonts/Xft2 displays:
zlib
fontconfig
iconv
zlib
freetype2
expat
freetype2
Xrender
renderproto
RECOMMENDED is removed. It becomes ABI_DEPENDS.
BUILDLINK_RECOMMENDED.foo becomes BUILDLINK_ABI_DEPENDS.foo.
BUILDLINK_DEPENDS.foo becomes BUILDLINK_API_DEPENDS.foo.
BUILDLINK_DEPENDS does not change.
IGNORE_RECOMMENDED (which defaulted to "no") becomes USE_ABI_DEPENDS
which defaults to "yes".
Added to obsolete.mk checking for IGNORE_RECOMMENDED.
I did not manually go through and fix any aesthetic tab/spacing issues.
I have tested the above patch on DragonFly building and packaging
subversion and pkglint and their many dependencies.
I have also tested USE_ABI_DEPENDS=no on my NetBSD workstation (where I
have used IGNORE_RECOMMENDED for a long time). I have been an active user
of IGNORE_RECOMMENDED since it was available.
As suggested, I removed the documentation sentences suggesting bumping for
"security" issues.
As discussed on tech-pkg.
I will commit to revbump, pkglint, pkg_install, createbuildlink separately.
Note that if you use wip, it will fail! I will commit to pkgsrc-wip
later (within day).
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
in the process. (More information on tech-pkg.)
Bump PKGREVISION and BUILDLINK_DEPENDS of all packages using libtool and
installing .la files.
Bump PKGREVISION (only) of all packages depending directly on the above
via a buildlink3 include.
All library names listed by *.la files no longer need to be listed
in the PLIST, e.g., instead of:
lib/libfoo.a
lib/libfoo.la
lib/libfoo.so
lib/libfoo.so.0
lib/libfoo.so.0.1
one simply needs:
lib/libfoo.la
and bsd.pkg.mk will automatically ensure that the additional library
names are listed in the installed package +CONTENTS file.
Also make LIBTOOLIZE_PLIST default to "yes".
support is useless in pkgsrc anyway, and it breaks the build on several
platforms because of confusion over what the build dir is to be
called. (possibly because of CONFIG_SUB_OVERRIDE?)
by moving the inclusion of buildlink3.mk files outside of the protected
region. This bug would be seen by users that have set PREFER_PKGSRC
or PREFER_NATIVE to non-default values.
BUILDLINK_PACKAGES should be ordered so that for any package in the
list, that package doesn't depend on any packages to the left of it
in the list. This ordering property is used to check for builtin
packages in the correct order. The problem was that including a
buildlink3.mk file for <pkg> correctly ensured that <pkg> was removed
from BUILDLINK_PACKAGES and appended to the end. However, since the
inclusion of any other buildlink3.mk files within that buildlink3.mk
was in a region that was protected against multiple inclusion, those
dependencies weren't also moved to the end of BUILDLINK_PACKAGES.
