876216 - Update libjpeg-turbo to version 1.3.0

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[NVD]

http://sourceforge.net/projects/libjpeg-turbo/files/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.

Plus the changes in http://sourceforge.net/projects/libjpeg-turbo/files/1.2.90%20%281.3beta1%29/

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Attachment: Update libjpeg-turbo to version 1.3.0 v1

https://tbpl.mozilla.org/?tree=Try&rev=f535eaa2daee

I'll request review when this is green. Justin, can you take a look at the jconfig.h change I made? MEM_SRCDST_SUPPORTED is newly-added and while I don't believe we need it, it would be good to get confirmation of that :)

Comment 2

[Justin Lebar (not reading bugmail)]

I agree we don't need MEM_SRCDST.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 758034 [details] [diff] [review]
Update libjpeg-turbo to version 1.3.0 v1

Justin, you said this might need security fuzzing?

Comment 4

[Justin Lebar (not reading bugmail)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #3)
> Comment on attachment 758034 [details] [diff] [review]
> Update libjpeg-turbo to version 1.3.0 v1
> 
> Justin, you said this might need security fuzzing?

Yeah, I think that would be appropriate.  I think decoder did it last time?  I'd be OK landing this before we fuzz it -- we can always back it out -- but that's a question for the sec team.

Comment 5

[Justin Lebar (not reading bugmail)]

Comment on attachment 758034 [details] [diff] [review]
Update libjpeg-turbo to version 1.3.0 v1

rs=me

Comment 6

[Christian Holler (:decoder)]

Typically cdiehl does this type of fuzzing, I currently don't have a setup running with jpeg :)

Comment 7

[Christoph Diehl [:posidron]]

Running.

:rforbes, interested in testing this on Windows with the new publisher?

Comment 8

[Ryan VanderMeulen [:RyanVM]]

cdiehl gave me the OK to land on IRC.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5eb7215f5ab8

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5eb7215f5ab8