From: DRC Date: Thu, 21 Nov 2013 18:32:48 +0000 (+0000) Subject: Fix CVE-2013-6629 and CVE-2013-6630 X-Git-Tag: 1.3.1~38 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=7ebf2941a981f75539f8298cb7e178607c937c14;p=libjpeg-turbo Fix CVE-2013-6629 and CVE-2013-6630 git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1089 632fc199-4ca6-4c93-a231-07263d6284db --- 7ebf2941a981f75539f8298cb7e178607c937c14 diff --cc ChangeLog.txt index 711e48e,9d5ae8d..7789d90 --- a/ChangeLog.txt +++ b/ChangeLog.txt @@@ -1,80 -1,9 +1,83 @@@ -1.2.2 +1.3.1 ===== -[1] The tjDecompressToYUV() function now supports the TJFLAG_FASTDCT flag. +[1] On Un*x systems, 'make install' now installs the libjpeg-turbo libraries +into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86, +and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just +x86-64. You can override this by overriding either the 'prefix' or 'libdir' +configure variables. -[2] The 32-bit supplementary package for amd64 Debian systems now provides +[2] The Windows installer now places a copy of the TurboJPEG DLLs in the same +directory as the rest of the libjpeg-turbo binaries. This was mainly done +to support TurboVNC 1.3, which bundles the DLLs in its Windows installation. +When using a 32-bit version of CMake on 64-bit Windows, it is impossible to +access the c:\WINDOWS\system32 directory, which made it impossible for the +TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL. + +[3] Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic +entropy coding (by passing arguments of -progressive -arithmetic to cjpeg or +jpegtran, for instance) would result in an error, "Requested feature was +omitted at compile time". + ++[4] Fixed a couple of issues whereby malformed JPEG images would cause ++libjpeg-turbo to use uninitialized memory during decompression. ++ + +1.3.0 +===== + +[1] 'make test' now works properly on FreeBSD, and it no longer requires the +md5sum executable to be present on other Un*x platforms. + +[2] Overhauled the packaging system: +-- To avoid conflict with vendor-supplied libjpeg-turbo packages, the +official RPMs and DEBs for libjpeg-turbo have been renamed to +"libjpeg-turbo-official". +-- The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the +official Linux and Mac packages, to avoid conflict with vendor-supplied +packages and also to streamline the packaging system. +-- Release packages are now created with the directory structure defined +by the configure variables "prefix", "bindir", "libdir", etc. (Un*x) or by the +CMAKE_INSTALL_PREFIX variable (Windows.) The exception is that the docs are +always located under the system default documentation directory on Un*x and Mac +systems, and on Windows, the TurboJPEG DLL is always located in the Windows +system directory. +-- To avoid confusion, official libjpeg-turbo packages on Linux/Unix platforms +(except for Mac) will always install the 32-bit libraries in +/opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64. +-- Fixed an issue whereby, in some cases, the libjpeg-turbo executables on Un*x +systems were not properly linking with the shared libraries installed by the +same package. +-- Fixed an issue whereby building the "installer" target on Windows when +WITH_JAVA=1 would fail if the TurboJPEG JAR had not been previously built. +-- Building the "install" target on Windows now installs files into the same +places that the installer does. + +[3] Fixed a Huffman encoder bug that prevented I/O suspension from working +properly. + + +1.2.90 (1.3 beta1) +================== + +[1] Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4, +11/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing. Note that the IDCT will +not be SIMD-accelerated when using any of these new scaling factors. + +[2] The TurboJPEG dynamic library is now versioned. It was not strictly +necessary to do so, because TurboJPEG uses versioned symbols, and if a function +changes in an ABI-incompatible way, that function is renamed and a legacy +function is provided to maintain backward compatibility. However, certain +Linux distro maintainers have a policy against accepting any library that isn't +versioned. + +[3] Extended the TurboJPEG Java API so that it can be used to compress a JPEG +image from and decompress a JPEG image to an arbitrary position in a large +image buffer. + +[4] The tjDecompressToYUV() function now supports the TJFLAG_FASTDCT flag. + +[5] The 32-bit supplementary package for amd64 Debian systems now provides symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32. This allows those libraries to be used on MultiArch-compatible systems (such as Ubuntu 11 and later) without setting the linker path.