Image loading libraries

Posted Sep 9, 2005 10:29 UTC (Fri) by ringerc (subscriber, #3071)
Parent article: Banner ads: worse than you thought

There's another point, other than security, in favour of trying to make image loading libraries as paranoid and robust as possible with their image handling.

Libraries like libjpeg, libtiff, libpng and friends are loaded into a program's address space, and have read/write access to most of the program's memory. If they do something that causes memory corruption, it'll often bring the whole app down - and not generally neatly. Similarly, if a library segfaults, it's very difficult for the host app to recover from this when it's possible at all. The best most apps can hope for is to emergency save their files and crash out politely.

Given this, image libraries are a core part of the stability of a desktop. Images come in from anywhere and everywhere, with all sorts of bizarre non-compliant aspects, mangling, and corruption. Apps will be unable to detect many of these, and must rely on the image loading library doing the right thing.

As far as I know, application authors have little they can do about this, short of shoving image library use out into a separate process and doing highly inefficient IPC to it. I've not been able to find out about any way of sanely isolating a library, anyway. (This and decent reflection are the two things that make C# sound attractive compared to C++ to me).

So ... we're at the mercy of image libraries. Freetype is in a similar category - apps just have to hope it's paranoid enough. There are enough crash reports in the Scribus bug tracker that have turned out to be bad images / bad fonts to suggest that these libraries aren't there yet in terms of robustness and paranoia.

In the end, this is about more than security. It's about the ability to build apps on a solid foundation.