On Tue, Jun 30, 2009 at 3:09 PM, Evan Martin<[email protected]> wrote: >> a) using the system libjpeg (at least on linux, if not the other >> platforms as well)
Distros want this too. The reasons *not* to do this are: 1) We'd be at the mercy of distros with respect to image decoder bugs. Historically everyone else has tended to disagree with us on how important security vulnerabilities are and how aggressively they should be pushed on users, so I don't expect the distro situation to be too different. 2) Ubuntu has demonstrated that they don't care about /usr/lib32 (https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/190227), so it's even less likely they'd update libjpeg there. >> b) compiling our libjpeg with boolean = int (at least on linux) This seems the simplest to me. It's not like we're saving 3 bytes of memory using a char instead of an int for these booleans -- they're likely passed around in 4-byte registers and 4-byte unpacked structs anyway. But I'm skeptical this really fixes the issue, as it'll still be broken on systems where the flag is flipped the *other* way. >> c) packaging our own version of gtk along with chrome (ha ha ha ha) >> d) somehow use the system libjpeg for gtk, and our libjpeg for chrome > e) rename all symbols in our version of libjpeg, like was done in > libpng (see third_party/libpng/pngusr.h) And this one seems the safest to me. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
