openSUSE Build Service

Overview Repositories Revisions Requests Users Attributes Meta

Revisions of libjpeg-turbo

buildservice-autocommit accepted request 859049 from

Petr Gajdos (pgajdos) over 3 years ago (revision 114)

baserev update by copy to link target

Petr Gajdos (pgajdos) committed over 3 years ago (revision 113)

- version update to 2.0.6
  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`.)
- modified sources
  % libjpeg-turbo.keyring

buildservice-autocommit accepted request 826188 from

Petr Gajdos (pgajdos) almost 4 years ago (revision 112)

baserev update by copy to link target

Petr Gajdos (pgajdos) accepted request 826111 from

Matthias Eliasson (elimat) almost 4 years ago (revision 111)

- Update to version 2.0.5
  * 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.
  * 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.
  * 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.
  * 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.
- Fix source verification
- Drop patches fixed upstream:
  * ctest-depends.patch
  * libjpeg-turbo-CVE-2020-13790.patch
- Run spec-cleaner
  * Remove package groups
  * Use make macros
- Update to version 2.0.5
  * 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.
  * 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.
  * 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.
  * 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.
- Drop patches fixed upstream:
  * ctest-depends.patch
  * libjpeg-turbo-CVE-2020-13790.patch
- Run spec-cleaner
  * Remove package groups
  * Use make macros

buildservice-autocommit accepted request 812575 from

Petr Gajdos (pgajdos) almost 4 years ago (revision 110)

baserev update by copy to link target

Petr Gajdos (pgajdos) committed almost 4 years ago (revision 109)

- security update
- added patches
  fix CVE-2020-13790 [bsc#1172491], heap-based buffer over-read in get_rgb_row() in rdppm.c via a malformed PPM input file
  + libjpeg-turbo-CVE-2020-13790.patch

Petr Gajdos (pgajdos) committed almost 4 years ago (revision 108)

- security update
- added patches
  fix CVE-2020-13790 [bsc#1172491], heap-based buffer over-read in get_rgb_row() in rdppm.c via a malformed PPM input file
  + libjpeg-turbo-CVE-2020-13790.patch

buildservice-autocommit accepted request 789669 from

Petr Gajdos (pgajdos) about 4 years ago (revision 107)

baserev update by copy to link target

Petr Gajdos (pgajdos) committed about 4 years ago (revision 106)

- libjpeg-turbo-issue-388.patch upstreamed

Petr Gajdos (pgajdos) committed about 4 years ago (revision 105)

Petr Gajdos (pgajdos) accepted request 789475 from

Aaron Stern (ukbeast89) about 4 years ago (revision 104)

- Upate to version 2.0.4:
- bug 388 was fixed upstream
  https://github.com/libjpeg-turbo/libjpeg-turbo/issues/388
- removed patches, as it is included in this release.
  * Fixed a regression in the Windows packaging system 
   (introduced by 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo 
   SDK for GCC and the 64-bit libjpeg-turbo SDK for Visual C++ were installed 
   on the same system, only one of them could be uninstalled.
  * Fixed a signed integer overflow and subsequent segfault that occurred when 
    attempting to decompress images with more than 715827882 pixels using the 64-bit C version of TJBench.
  * Fixed out-of-bounds write in tjDecompressToYUV2() and tjDecompressToYUVPlanes() 
    (sometimes manifesting as a double free) that occurred when attempting to decompress 
    grayscale JPEG images that were compressed with a sampling factor other than 1 
    (for instance, with cjpeg -grayscale -sample 2x2).
  * Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to incorrectly 
    identify some JPEG images with unusual sampling factors as 4:4:4 JPEG images. 
    This was known to cause a buffer overflow when attempting to decompress some such images using 
    tjDecompressToYUV2() or tjDecompressToYUVPlanes().
  * Fixed an issue, detected by ASan, whereby attempting to losslessly transform a specially-crafted 
    malformed JPEG image containing an extremely-high-frequency coefficient block 
    (junk image data that could never be generated by a legitimate JPEG compressor) could cause the 
    Huffman encoder's local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) 
    Given that the buffer overrun was fully contained within the stack and did not cause a segfault 
    or other user-visible errant behavior, and given that the lossless transformer (unlike the decompressor) 
    is not generally exposed to arbitrary data exploits, this issue did not likely pose a security risk.
    The ARM 64-bit (ARMv8) NEON SIMD assembly code now stores constants in a separate read-only data 
    section rather than in the text section, to support execute-only memory layouts.
- Upate to version 2.0.4:
  * Fixed a regression in the Windows packaging system 
   (introduced by 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo 
   SDK for GCC and the 64-bit libjpeg-turbo SDK for Visual C++ were installed 
   on the same system, only one of them could be uninstalled.
  * Fixed a signed integer overflow and subsequent segfault that occurred when 
    attempting to decompress images with more than 715827882 pixels using the 64-bit C version of TJBench.
  * Fixed out-of-bounds write in tjDecompressToYUV2() and tjDecompressToYUVPlanes() 
    (sometimes manifesting as a double free) that occurred when attempting to decompress 
    grayscale JPEG images that were compressed with a sampling factor other than 1 
    (for instance, with cjpeg -grayscale -sample 2x2).
  * Fixed a regression introduced by 2.0.2[5] that caused the TurboJPEG API to incorrectly 
    identify some JPEG images with unusual sampling factors as 4:4:4 JPEG images. 
    This was known to cause a buffer overflow when attempting to decompress some such images using 
    tjDecompressToYUV2() or tjDecompressToYUVPlanes().
  * Fixed an issue, detected by ASan, whereby attempting to losslessly transform a specially-crafted 
    malformed JPEG image containing an extremely-high-frequency coefficient block 
    (junk image data that could never be generated by a legitimate JPEG compressor) could cause the 
    Huffman encoder's local buffer to be overrun. (Refer to 1.4.0[9] and 1.4beta1[15].) 
    Given that the buffer overrun was fully contained within the stack and did not cause a segfault 
    or other user-visible errant behavior, and given that the lossless transformer (unlike the decompressor) 
    is not generally exposed to arbitrary data exploits, this issue did not likely pose a security risk.
    The ARM 64-bit (ARMv8) NEON SIMD assembly code now stores constants in a separate read-only data 
    section rather than in the text section, to support execute-only memory layouts.

Petr Gajdos (pgajdos) accepted request 786667 from

John Whately (GeoDerp) about 4 years ago (revision 103)

- Added If statments for Fedora not having sertain openSUSE macros
- Added If statments for Fedora not having sertain openSUSE macros

buildservice-autocommit accepted request 748021 from

Petr Gajdos (pgajdos) over 4 years ago (revision 102)

baserev update by copy to link target

Petr Gajdos (pgajdos) committed over 4 years ago (revision 101)

Petr Gajdos (pgajdos) committed over 4 years ago (revision 100)

- fix upstream bug 388 [bsc#1156402]
- added patches
  https://github.com/libjpeg-turbo/libjpeg-turbo/issues/388
  + libjpeg-turbo-issue-388.patch

buildservice-autocommit accepted request 735600 from

Petr Gajdos (pgajdos) over 4 years ago (revision 99)

baserev update by copy to link target

Petr Gajdos (pgajdos) accepted request 735401 from

Bjørn Lie (iznogood) over 4 years ago (revision 98)

New upstream release

buildservice-autocommit accepted request 689002 from

Petr Gajdos (pgajdos) about 5 years ago (revision 97)

baserev update by copy to link target

Petr Gajdos (pgajdos) committed about 5 years ago (revision 96)

- use -O0 for debugging like everywhere (better experience)

buildservice-autocommit accepted request 684675 from

Petr Gajdos (pgajdos) about 5 years ago (revision 95)

baserev update by copy to link target

Displaying revisions 41 - 60 of 154

Places

Revisions of libjpeg-turbo

Places