From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH] libjpeg: Update to version 2.1.4 Date: Tue, 27 Dec 2022 16:12:50 +0000 Message-ID: <0b6d94c6-ae7d-18d3-1cca-410f81c997ee@ipfire.org> In-Reply-To: <20221227120002.12161-11-adolf.belka@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7406629400381755465==" List-Id: --===============7406629400381755465== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Reviewed-by: Peter M=C3=BCller > - Update from version 2.0.4 to 2.1.4 > - Update of rootfile > - Changelog > 2.1.4 > ### Significant changes relative to 2.1.3 > 1. Fixed a regression introduced in 2.1.3 that caused build failures with > Visual Studio 2010. > 2. The `tjDecompressHeader3()` function in the TurboJPEG C API and the > `TJDecompressor.setSourceImage()` method in the TurboJPEG Java API now acc= ept > "abbreviated table specification" (AKA "tables-only") datastreams, which c= an be > used to prime the decompressor with quantization and Huffman tables that c= an be > used when decompressing subsequent "abbreviated image" datastreams. > 3. libjpeg-turbo now performs run-time detection of AltiVec instructions on > OS X/PowerPC systems if AltiVec instructions are not enabled at compile ti= me. > This allows both AltiVec-equipped (PowerPC G4 and G5) and non-AltiVec-equi= pped > (PowerPC G3) CPUs to be supported using the same build of libjpeg-turbo. > 4. Fixed an error ("Bogus virtual array access") that occurred when attemp= ting > to decompress a progressive JPEG image with a height less than or equal to= one > iMCU (8 * the vertical sampling factor) using buffered-image mode with > interblock smoothing enabled. This was a regression introduced by > 2.1 beta1[6(b)]. > 5. Fixed two issues that prevented partial image decompression from working > properly with buffered-image mode: > - Attempting to call `jpeg_crop_scanline()` after > `jpeg_start_decompress()` but before `jpeg_start_output()` resulted in an = error > ("Improper call to JPEG library in state 207".) > - Attempting to use `jpeg_skip_scanlines()` resulted in an error ("Bo= gus > virtual array access") under certain circumstances. > 2.1.3 > ### Significant changes relative to 2.1.2 > 1. Fixed a regression introduced by 2.0 beta1[7] whereby cjpeg compressed = PGM > input files into full-color JPEG images unless the `-grayscale` option was > used. > 2. cjpeg now automatically compresses GIF and 8-bit BMP input files into > grayscale JPEG images if the input files contain only shades of gray. > 3. The build system now enables the intrinsics implementation of the AArch= 64 > (Arm 64-bit) Neon SIMD extensions by default when using GCC 12 or later. > 4. Fixed a segfault that occurred while decompressing a 4:2:0 JPEG image u= sing > the merged (non-fancy) upsampling algorithms (that is, with > `cinfo.do_fancy_upsampling` set to `FALSE`) along with `jpeg_crop_scanline= ()`. > Specifically, the segfault occurred if the number of bytes remaining in the > output buffer was less than the number of bytes required to represent one > uncropped scanline of the output image. For that reason, the issue could = only > be reproduced using the libjpeg API, not using djpeg. > 2.1.2 > ### Significant changes relative to 2.1.1 > 1. Fixed a regression introduced by 2.1 beta1[13] that caused the remaining > GAS implementations of AArch64 (Arm 64-bit) Neon SIMD functions (which are= used > by default with GCC for performance reasons) to be placed in the `.rodata` > section rather than in the `.text` section. This caused the GNU linker to > automatically place the `.rodata` section in an executable segment, which > prevented libjpeg-turbo from working properly with other linkers and also > represented a potential security risk. > 2. Fixed an issue whereby the `tjTransform()` function incorrectly compute= d the > MCU block size for 4:4:4 JPEG images with non-unary sampling factors and t= hus > unduly rejected some cropping regions, even though those regions aligned w= ith > 8x8 MCU block boundaries. > 3. Fixed a regression introduced by 2.1 beta1[13] that caused the build sy= stem > to enable the Arm Neon SIMD extensions when targetting Armv6 and other leg= acy > architectures that do not support Neon instructions. > 4. libjpeg-turbo now performs run-time detection of AltiVec instructions on > FreeBSD/PowerPC systems if AltiVec instructions are not enabled at compile > time. This allows both AltiVec-equipped and non-AltiVec-equipped CPUs to = be > supported using the same build of libjpeg-turbo. > 5. cjpeg now accepts a `-strict` argument similar to that of djpeg and > jpegtran, which causes the compressor to abort if an LZW-compressed GIF in= put > image contains incomplete or corrupt image data. > 2.1.1 > ### Significant changes relative to 2.1.0 > 1. Fixed a regression introduced in 2.1.0 that caused build failures with > non-GCC-compatible compilers for Un*x/Arm platforms. > 2. Fixed a regression introduced by 2.1 beta1[13] that prevented the Arm 3= 2-bit > (AArch32) Neon SIMD extensions from building unless the C compiler flags > included `-mfloat-abi=3Dsoftfp` or `-mfloat-abi=3Dhard`. > 3. Fixed an issue in the AArch32 Neon SIMD Huffman encoder whereby relianc= e on > undefined C compiler behavior led to crashes ("SIGBUS: illegal alignment")= on > Android systems when running AArch32/Thumb builds of libjpeg-turbo built w= ith > recent versions of Clang. > 4. Added a command-line argument (`-copy icc`) to jpegtran that causes it = to > copy only the ICC profile markers from the source file and discard any oth= er > metadata. > 5. libjpeg-turbo should now build and run on CHERI-enabled architectures, = which > use capability pointers that are larger than the size of `size_t`. > 6. Fixed a regression (CVE-2021-37972) introduced by 2.1 beta1[5] that cau= sed a > segfault in the 64-bit SSE2 Huffman encoder when attempting to losslessly > transform a specially-crafted malformed JPEG image. > 2.1.0 > ### Significant changes relative to 2.1 beta1 > 1. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to > decompress certain progressive JPEG images with one or more component plan= es of > width 8 or less caused a buffer overrun. > 2. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to > decompress a specially-crafted malformed progressive JPEG image caused the > block smoothing algorithm to read from uninitialized memory. > 3. Fixed an issue in the Arm Neon SIMD Huffman encoders that caused the > encoders to generate incorrect results when using the Clang compiler with > Visual Studio. > 4. Fixed a floating point exception (CVE-2021-20205) that occurred when > attempting to compress a specially-crafted malformed GIF image with a spec= ified > image width of 0 using cjpeg. > 5. Fixed a regression introduced by 2.0 beta1[15] whereby attempting to > generate a progressive JPEG image on an SSE2-capable CPU using a scan scri= pt > containing one or more scans with lengths divisible by 32 and non-zero > successive approximation low bit positions would, under certain circumstan= ces, > result in an error ("Missing Huffman code table entry") and an invalid JPEG > image. > 6. Introduced a new flag (`TJFLAG_LIMITSCANS` in the TurboJPEG C API and > `TJ.FLAG_LIMIT_SCANS` in the TurboJPEG Java API) and a corresponding TJBen= ch > command-line argument (`-limitscans`) that causes the TurboJPEG decompress= ion > and transform functions/operations to return/throw an error if a progressi= ve > JPEG image contains an unreasonably large number of scans. This allows > applications that use the TurboJPEG API to guard against an exploit of the > progressive JPEG format described in the report > ["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/upl= oads/About/TwoIssueswiththeJPEGStandard.pdf). > 7. The PPM reader now throws an error, rather than segfaulting (due to a b= uffer > overrun) or generating incorrect pixels, if an application attempts to use= the > `tjLoadImage()` function to load a 16-bit binary PPM file (a binary PPM fi= le > with a maximum value greater than 255) into a grayscale image buffer or to= load > a 16-bit binary PGM file into an RGB image buffer. > 8. Fixed an issue in the PPM reader that caused incorrect pixels to be > generated when using the `tjLoadImage()` function to load a 16-bit binary = PPM > file into an extended RGB image buffer. > 9. Fixed an issue whereby, if a JPEG buffer was automatically re-allocated= by > one of the TurboJPEG compression or transform functions and an error > subsequently occurred during compression or transformation, the JPEG buffer > pointer passed by the application was not updated when the function return= ed. > 2.0.90 (2.1 beta1) > ### Significant changes relative to 2.0.6: > 1. The build system, x86-64 SIMD extensions, and accelerated Huffman codec= now > support the x32 ABI on Linux, which allows for using x86-64 instructions w= ith > 32-bit pointers. The x32 ABI is generally enabled by adding `-mx32` to the > compiler flags. > Caveats: > - CMake 3.9.0 or later is required in order for the build system to > automatically detect an x32 build. > - Java does not support the x32 ABI, and thus the TurboJPEG Java API = will > automatically be disabled with x32 builds. > 2. Added Loongson MMI SIMD implementations of the RGB-to-grayscale, 4:2:2 = fancy > chroma upsampling, 4:2:2 and 4:2:0 merged chroma upsampling/color conversi= on, > and fast integer DCT/IDCT algorithms. Relative to libjpeg-turbo 2.0.x, th= is > speeds up: > - the compression of RGB source images into grayscale JPEG images by > approximately 20% > - the decompression of 4:2:2 JPEG images by approximately 40-60% when > using fancy upsampling > - the decompression of 4:2:2 and 4:2:0 JPEG images by approximately > 15-20% when using merged upsampling > - the compression of RGB source images by approximately 30-45% when u= sing > the fast integer DCT > - the decompression of JPEG images into RGB destination images by > approximately 2x when using the fast integer IDCT > The overall decompression speedup for RGB images is now approximately > 2.3-3.7x (compared to 2-3.5x with libjpeg-turbo 2.0.x.) > 3. 32-bit (Armv7 or Armv7s) iOS builds of libjpeg-turbo are no longer > supported, and the libjpeg-turbo build system can no longer be used to pac= kage > such builds. 32-bit iOS apps cannot run in iOS 11 and later, and the App = Store > no longer allows them. > 4. 32-bit (i386) OS X/macOS builds of libjpeg-turbo are no longer supporte= d, > and the libjpeg-turbo build system can no longer be used to package such > builds. 32-bit Mac applications cannot run in macOS 10.15 "Catalina" and > later, and the App Store no longer allows them. > 5. The SSE2 (x86 SIMD) and C Huffman encoding algorithms have been > significantly optimized, resulting in a measured average overall compressi= on > speedup of 12-28% for 64-bit code and 22-52% for 32-bit code on various In= tel > and AMD CPUs, as well as a measured average overall compression speedup of > 0-23% on platforms that do not have a SIMD-accelerated Huffman encoding > implementation. > 6. The block smoothing algorithm that is applied by default when decompres= sing > progressive Huffman-encoded JPEG images has been improved in the following > ways: > - The algorithm is now more fault-tolerant. Previously, if a particu= lar > scan was incomplete, then the smoothing parameters for the incomplete scan > would be applied to the entire output image, including the parts of the im= age > that were generated by the prior (complete) scan. Visually, this had the > effect of removing block smoothing from lower-frequency scans if they were > followed by an incomplete higher-frequency scan. libjpeg-turbo now applies > block smoothing parameters to each iMCU row based on which scan generated = the > pixels in that row, rather than always using the block smoothing parameter= s for > the most recent scan. > - When applying block smoothing to DC scans, a Gaussian-like kernel w= ith a > 5x5 window is used to reduce the "blocky" appearance. > 7. Added SIMD acceleration for progressive Huffman encoding on Arm platfor= ms. > This speeds up the compression of full-color progressive JPEGs by about 30= -40% > on average (relative to libjpeg-turbo 2.0.x) when using modern Arm CPUs. > 8. Added configure-time and run-time auto-detection of Loongson MMI SIMD > instructions, so that the Loongson MMI SIMD extensions can be included in = any > MIPS64 libjpeg-turbo build. > 9. Added fault tolerance features to djpeg and jpegtran, mainly to demonst= rate > methods by which applications can guard against the exploits of the JPEG f= ormat > described in the report > ["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/upl= oads/About/TwoIssueswiththeJPEGStandard.pdf). > - Both programs now accept a `-maxscans` argument, which can be used = to > limit the number of allowable scans in the input file. > - Both programs now accept a `-strict` argument, which can be used to > treat all warnings as fatal. > 10. CMake package config files are now included for both the libjpeg and > TurboJPEG API libraries. This facilitates using libjpeg-turbo with CMake's > `find_package()` function. For example: > find_package(libjpeg-turbo CONFIG REQUIRED) > add_executable(libjpeg_program libjpeg_program.c) > target_link_libraries(libjpeg_program PUBLIC libjpeg-turbo::jpeg) > add_executable(libjpeg_program_static libjpeg_program.c) > target_link_libraries(libjpeg_program_static PUBLIC > libjpeg-turbo::jpeg-static) > add_executable(turbojpeg_program turbojpeg_program.c) > target_link_libraries(turbojpeg_program PUBLIC > libjpeg-turbo::turbojpeg) > add_executable(turbojpeg_program_static turbojpeg_program.c) > target_link_libraries(turbojpeg_program_static PUBLIC > libjpeg-turbo::turbojpeg-static) > 11. Since the Unisys LZW patent has long expired, cjpeg and djpeg can now > read/write both LZW-compressed and uncompressed GIF files (feature ported = from > jpeg-6a and jpeg-9d.) > 12. jpegtran now includes the `-wipe` and `-drop` options from jpeg-9a and > jpeg-9d, as well as the ability to expand the image size using the `-crop` > option. Refer to jpegtran.1 or usage.txt for more details. > 13. Added a complete intrinsics implementation of the Arm Neon SIMD extens= ions, > thus providing SIMD acceleration on Arm platforms for all of the algorithms > that are SIMD-accelerated on x86 platforms. This new implementation is > significantly faster in some cases than the old GAS implementation-- > depending on the algorithms used, the type of CPU core, and the compiler. = GCC, > as of this writing, does not provide a full or optimal set of Neon intrins= ics, > so for performance reasons, the default when building libjpeg-turbo with G= CC is > to continue using the GAS implementation of the following algorithms: > - 32-bit RGB-to-YCbCr color conversion > - 32-bit fast and accurate inverse DCT > - 64-bit RGB-to-YCbCr and YCbCr-to-RGB color conversion > - 64-bit accurate forward and inverse DCT > - 64-bit Huffman encoding > A new CMake variable (`NEON_INTRINSICS`) can be used to override this > default. > Since the new intrinsics implementation includes SIMD acceleration > for merged upsampling/color conversion, 1.5.1[5] is no longer necessary an= d has > been reverted. > 14. The Arm Neon SIMD extensions can now be built using Visual Studio. > 15. The build system can now be used to generate a universal x86-64 + Armv8 > libjpeg-turbo SDK package for both iOS and macOS. > 2.0.6 > ### Significant changes relative to 2.0.5: > 1. Fixed "using JNI after critical get" errors that occurred on Android > platforms when using any of the YUV encoding/compression/decompression/dec= oding > methods in the TurboJPEG Java API. > 2. Fixed or worked around multiple issues with `jpeg_skip_scanlines()`: > - Fixed segfaults or "Corrupt JPEG data: premature end of data segmen= t" > errors in `jpeg_skip_scanlines()` that occurred when decompressing 4:2:2 or > 4:2:0 JPEG images using merged (non-fancy) upsampling/color conversion (th= at > is, when setting `cinfo.do_fancy_upsampling` to `FALSE`.) 2.0.0[6] was a > similar fix, but it did not cover all cases. > - `jpeg_skip_scanlines()` now throws an error if two-pass color > quantization is enabled. Two-pass color quantization never worked properly > with `jpeg_skip_scanlines()`, and the issues could not readily be fixed. > - Fixed an issue whereby `jpeg_skip_scanlines()` always returned 0 wh= en > skipping past the end of an image. > 3. The Arm 64-bit (Armv8) Neon SIMD extensions can now be built using MinGW > toolchains targetting Arm64 (AArch64) Windows binaries. > 4. Fixed unexpected visual artifacts that occurred when using > `jpeg_crop_scanline()` and interblock smoothing while decompressing only t= he DC > scan of a progressive JPEG image. > 5. Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-comp= onent > JPEG support (`WITH_12BIT`) was enabled along with libjpeg v7 or libjpeg v8 > API/ABI emulation (`WITH_JPEG7` or `WITH_JPEG8`.) > 2.0.5 > ### Significant changes relative to 2.0.4: > 1. Worked around issues in the MIPS DSPr2 SIMD extensions that caused fail= ures > in the libjpeg-turbo regression tests. Specifically, the > `jsimd_h2v1_downsample_dspr2()` and `jsimd_h2v2_downsample_dspr2()` functi= ons > in the MIPS DSPr2 SIMD extensions are now disabled until/unless they can be > fixed, and other functions that are incompatible with big endian MIPS CPUs= are > disabled when building libjpeg-turbo for such CPUs. > 2. Fixed an oversight in the `TJCompressor.compress(int)` method in the > TurboJPEG Java API that caused an error ("java.lang.IllegalStateException:= No > source image is associated with this instance") when attempting to use that > method to compress a YUV image. > 3. Fixed an issue (CVE-2020-13790) in the PPM reader that caused a buffer > overrun in cjpeg, TJBench, or the `tjLoadImage()` function if one of the v= alues > in a binary PPM/PGM input file exceeded the maximum value defined in the f= ile's > header and that maximum value was less than 255. libjpeg-turbo 1.5.0 alre= ady > included a similar fix for binary PPM/PGM files with maximum values greater > than 255. > 4. The TurboJPEG API library's global error handler, which is used in func= tions > such as `tjBufSize()` and `tjLoadImage()` that do not require a TurboJPEG > instance handle, is now thread-safe on platforms that support thread-local > storage. >=20 > Signed-off-by: Adolf Belka > --- > config/rootfiles/common/libjpeg | 5 +++++ > lfs/libjpeg | 6 +++--- > 2 files changed, 8 insertions(+), 3 deletions(-) >=20 > diff --git a/config/rootfiles/common/libjpeg b/config/rootfiles/common/libj= peg > index eb74d2c50..74c101854 100644 > --- a/config/rootfiles/common/libjpeg > +++ b/config/rootfiles/common/libjpeg > @@ -9,6 +9,11 @@ > #usr/include/jmorecfg.h > #usr/include/jpeglib.h > #usr/include/turbojpeg.h > +#usr/lib/cmake/libjpeg-turbo > +#usr/lib/cmake/libjpeg-turbo/libjpeg-turboConfig.cmake > +#usr/lib/cmake/libjpeg-turbo/libjpeg-turboConfigVersion.cmake > +#usr/lib/cmake/libjpeg-turbo/libjpeg-turboTargets-release.cmake > +#usr/lib/cmake/libjpeg-turbo/libjpeg-turboTargets.cmake > #usr/lib/libjpeg.so > usr/lib/libjpeg.so.8 > usr/lib/libjpeg.so.8.2.2 > diff --git a/lfs/libjpeg b/lfs/libjpeg > index 6808640a4..b9c9d3cd8 100644 > --- a/lfs/libjpeg > +++ b/lfs/libjpeg > @@ -1,7 +1,7 @@ > ##########################################################################= ##### > # = # > # IPFire.org - A linux based firewall = # > -# Copyright (C) 2007-2020 IPFire Team = # > +# Copyright (C) 2007-2022 IPFire Team = # > # = # > # This program is free software: you can redistribute it and/or modify = # > # it under the terms of the GNU General Public License as published by = # > @@ -24,7 +24,7 @@ > =20 > include Config > =20 > -VER =3D 2.0.4 > +VER =3D 2.1.4 > =20 > THISAPP =3D libjpeg-turbo-$(VER) > DL_FILE =3D $(THISAPP).tar.gz > @@ -40,7 +40,7 @@ objects =3D $(DL_FILE) > =20 > $(DL_FILE) =3D $(DL_FROM)/$(DL_FILE) > =20 > -$(DL_FILE)_BLAKE2 =3D 9be870a5bafaae279646941b848b69fdf7c95ec08a686b01674f= 473ef33fe5923a04ba8a2d57df84384530308ca46fc3880a404c0eff769129417a553faed3bb > +$(DL_FILE)_BLAKE2 =3D 80ffd77d58a37eae0bdc1868d994f34ea52c13e2624c720b1d0b= 6ec4d6d14b16911163ccd4009c8d6eda214f31e1fff78bb7eb4739ae6589d0fd8c7008c0e972 > =20 > install : $(TARGET) > =20 --===============7406629400381755465==--