In combination with --datadir=/usr sorted it out for me. (thanks to the BLFS book for the hint on that)

Note: I'm not using mancha's slackbuild so the variable names may need adjusting.


Also, be aware that aaa_elflibs contains both a libjpeg.so.8 and a libjpeg.so.62 (which doesn't appear to be included in any other packages on the system).


edit: ahh, sorry, nevermind, I see mancha has already fixed it.

libjpeg-turbo up and running here. Seems snappy, though I can't say I ever noticed the old one feeling slow.

speed: I was using original libjpeg.Slackbuild script to build libjpeg-turbo, it has same problem. fixed with your suggestion.

I finally got around to benchmarking libjpeg-turbo on an x86 system by measuring compression and decompression megapixels/second rates for grayscale and chroma subsampling 4:2:0, 4:2:2, and 4:4:4.

• Compression
  libjpeg-turbo outperforms libjpeg-8a by 300%; ranging from 280% (grayscale) to 330% (chroma subsampling 4:2:0).
  
  
• Decompression
  results are slightly less striking but impressive all the same. On average libjpeg-turbo outperforms libjpeg-8a by 225%; ranging from 160% (grayscale) to 280% (chroma subsampling 4:2:0).

Aside from performance, another reason to consider libjpeg-turbo for the next development cycle is its adoption by Google, Mozilla, and numerous Linux distributions. With more eyeballs scrutinizing code it is reasonable to expect bugs and vulnerabilities will get more quickly identified/resolved.

Can I take the lack of negative reports on this thread as a good sign?

--mancha

PS This thread morphed from my initial vulnerability/patch announcement into a discussion about libjpeg-turbo which I agree is far more interesting. However, if I can turn to post #1 for a second, I've not seen any security releases for libjpeg on Slackware 12.1 through 14.1. Is Pat not really tracking LQ these days?

Thanks for bringing this up.
Mr. Volkerding may be on a well deserved vacation (I don't really know), but I was surprised when libjpeg wasn't included in the last batch of security upgrades.

6629 is described as a "information exposure/read from uninitialised memory" issue. I've seen much worse than this left unpatched in the past as Pat tends to only patch things that are at real risk of exploitation and which could result in a compromise.

It's really no different than all the bugs that remain unpatched in the kernel due to Slackware's policy of not providing all the stable kernel updates in /patches. If one were being kind, one might describe Slackware's attitude to security weaknesses like this as "pragmatic". This is of course a little unsettling for those of us of the paranoid persuasion who like to dot all their i's, but given Slackware's limited resource pool I think it's understandable.

I expect this will remain unpatched unless someone can demonstrate a way to use this for arbitrary code execution or worse.


As for libjpeg-turbo. It's been behaving just fine here.

Looks like RHEL and clones just got around to patching 6629.

Both Red Hat and Debian ended up taking the same approach I did (using Google/libjpeg-turbo's solution over Ghostscript/IJG's) for their IJG libjpeg-6b and libjpeg-8 fixes (CVE-2013-6629).

Also, the recent set of Mozilla releases (Firefox 26, Firefox ESR 24.2, Thunderbird 24.2, Seamonkey 2.23) includes a fix for the embedded libjpeg-turbo (CVE-2013-6629 & CVE-2013-6630).

--mancha

So, how do we get our system to use libjpeg-turbo? Is it as simple as just uninstalling the regular libjpeg?

I'm using libjepg-turbo for some years now on x86 and x86_64 without problems. Nothing had to be recompiled, what i compiled against libjepg-turbo did work.

Franzen