Re: [PATCH] libjpeg: Update to version 2.1.4

["Peter Müller" <peter.mueller@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 21091 bytes --]

Reviewed-by: Peter Müller <peter.mueller(a)ipfire.org>

> - 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 accept
> 	"abbreviated table specification" (AKA "tables-only") datastreams, which can be
> 	used to prime the decompressor with quantization and Huffman tables that can 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 time.
> 	This allows both AltiVec-equipped (PowerPC G4 and G5) and non-AltiVec-equipped
> 	(PowerPC G3) CPUs to be supported using the same build of libjpeg-turbo.
> 	4. Fixed an error ("Bogus virtual array access") that occurred when attempting
> 	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 ("Bogus
> 	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 AArch64
> 	(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 using
> 	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 computed the
> 	MCU block size for 4:4:4 JPEG images with non-unary sampling factors and thus
> 	unduly rejected some cropping regions, even though those regions aligned with
> 	8x8 MCU block boundaries.
> 	3. Fixed a regression introduced by 2.1 beta1[13] that caused the build system
> 	to enable the Arm Neon SIMD extensions when targetting Armv6 and other legacy
> 	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 input
> 	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 32-bit
> 	(AArch32) Neon SIMD extensions from building unless the C compiler flags
> 	included `-mfloat-abi=softfp` or `-mfloat-abi=hard`.
> 	3. Fixed an issue in the AArch32 Neon SIMD Huffman encoder whereby reliance on
> 	undefined C compiler behavior led to crashes ("SIGBUS: illegal alignment") on
> 	Android systems when running AArch32/Thumb builds of libjpeg-turbo built with
> 	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 other
> 	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 caused 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 planes 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 specified
> 	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 script
> 	containing one or more scans with lengths divisible by 32 and non-zero
> 	successive approximation low bit positions would, under certain circumstances,
> 	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 TJBench
> 	command-line argument (`-limitscans`) that causes the TurboJPEG decompression
> 	and transform functions/operations to return/throw an error if a progressive
> 	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/uploads/About/TwoIssueswiththeJPEGStandard.pdf).
> 	7. The PPM reader now throws an error, rather than segfaulting (due to a buffer
> 	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 file
> 	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 returned.
>     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 with
> 	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 conversion,
> 	and fast integer DCT/IDCT algorithms.  Relative to libjpeg-turbo 2.0.x, this
> 	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 using
> 	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 package
> 	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 supported,
> 	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 compression
> 	speedup of 12-28% for 64-bit code and 22-52% for 32-bit code on various Intel
> 	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 decompressing
> 	progressive Huffman-encoded JPEG images has been improved in the following
> 	ways:
> 	     - The algorithm is now more fault-tolerant.  Previously, if a particular
> 	scan was incomplete, then the smoothing parameters for the incomplete scan
> 	would be applied to the entire output image, including the parts of the image
> 	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 parameters for
> 	the most recent scan.
> 	     - When applying block smoothing to DC scans, a Gaussian-like kernel with a
> 	5x5 window is used to reduce the "blocky" appearance.
> 	7. Added SIMD acceleration for progressive Huffman encoding on Arm platforms.
> 	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 demonstrate
> 	methods by which applications can guard against the exploits of the JPEG format
> 	described in the report
> 	["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/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 extensions,
> 	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 intrinsics,
> 	so for performance reasons, the default when building libjpeg-turbo with GCC 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 and 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/decoding
> 	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 segment"
> 	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 (that
> 	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 when
> 	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 the DC
> 	scan of a progressive JPEG image.
> 	5. Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-component
> 	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 failures
> 	in the libjpeg-turbo regression tests.  Specifically, the
> 	`jsimd_h2v1_downsample_dspr2()` and `jsimd_h2v2_downsample_dspr2()` functions
> 	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 values
> 	in a binary PPM/PGM input file exceeded the maximum value defined in the file's
> 	header and that maximum value was less than 255.  libjpeg-turbo 1.5.0 already
> 	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 functions
> 	such as `tjBufSize()` and `tjLoadImage()` that do not require a TurboJPEG
> 	instance handle, is now thread-safe on platforms that support thread-local
> 	storage.
> 
> Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org>
> ---
>  config/rootfiles/common/libjpeg | 5 +++++
>  lfs/libjpeg                     | 6 +++---
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/config/rootfiles/common/libjpeg b/config/rootfiles/common/libjpeg
> 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  <info(a)ipfire.org>                     #
> +# Copyright (C) 2007-2022  IPFire Team  <info(a)ipfire.org>                     #
>  #                                                                             #
>  # 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 @@
>  
>  include Config
>  
> -VER        = 2.0.4
> +VER        = 2.1.4
>  
>  THISAPP    = libjpeg-turbo-$(VER)
>  DL_FILE    = $(THISAPP).tar.gz
> @@ -40,7 +40,7 @@ objects = $(DL_FILE)
>  
>  $(DL_FILE) = $(DL_FROM)/$(DL_FILE)
>  
> -$(DL_FILE)_BLAKE2 = 9be870a5bafaae279646941b848b69fdf7c95ec08a686b01674f473ef33fe5923a04ba8a2d57df84384530308ca46fc3880a404c0eff769129417a553faed3bb
> +$(DL_FILE)_BLAKE2 = 80ffd77d58a37eae0bdc1868d994f34ea52c13e2624c720b1d0b6ec4d6d14b16911163ccd4009c8d6eda214f31e1fff78bb7eb4739ae6589d0fd8c7008c0e972
>  
>  install : $(TARGET)
>