Opened 8 years ago
Closed 8 years ago
#9460 closed enhancement (fixed)
libjpeg-turbo-1.5.2
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | 8.1 |
Component: | BOOK | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description ¶
New point version.
Change History (3)
comment:1 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 8 years ago
Note:
See TracTickets
for help on using tickets.
1.5.2 =====
### Significant changes relative to 1.5.1:
-nowrite
switch was accidentally enabled by default.)jpeg_skip_scanlines()
andjpeg_crop_scanlines()
functions were not being included in jpeg7.dll when libjpeg-turbo was built with-DWITH_JPEG7=1
and-DWITH_MEMSRCDST=1
.-copy all
must be passed to jpegtran in order to transfer the EXIF tags from the source image to the destination image.-O1
and higher but not with GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error after a TurboJPEG API function allocated a local buffer.max_memory_to_use
structure member in jpeg\_memory\_mgr, which can be set to the maximum amount of memory (in bytes) that libjpeg-turbo should use during decompression or multi-pass (including progressive) compression. This limit can also be set using theJPEGMEM
environment variable or using the-maxmemory
switch in cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.) This has been a documented feature of libjpeg since v5, but themalloc()
/free()
implementation of the memory manager (jmemnobs.c) never implemented the feature. Restricting libjpeg-turbo's memory usage is useful for two reasons: it allows testers to more easily work around the 2 GB limit in libFuzzer, and it allows developers of security-sensitive applications to more easily defend against one of the progressive JPEG exploits (LJT-01-004) identified in [this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About /TwoIssueswiththeJPEGStandard.pdf).-warmup
option is now used to specify the amount of warmup time rather than the number of warmup iterations.short jump is out of range
) that occurred when assembling the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a regression introduced by 1.5 beta1[12].