We've kicked this idea around for some time but haven't yet implemented it.
It would be great to have a nice little daemon for doing image resizes safely:
- No more ImageMagick shell-character-exploit or buffer-overflow scares
- Reduce and unify library and subprogram dependencies for application servers
(vs varying versions of ImageMagick, librsvg, libart/cairo, freetype, etc)
- Integrate a nice SVG renderer like Batik
- Potential to isolate CPU and memory usage by running on separate boxes
Requirements:
- downscale PNG -> PNG
- downscale JPEG -> JPEG
- downscale GIF -> GIF
- rasterize SVG -> PNG
- The SVG renderer must be used in a restricted mode: a SVG must not be able to
include resources loadeded from disk or the network, as this could be a security
vulnerability.
- Any alpha-transparent PNGs must set the background color chunk to white
to avoid weird unexpected colors in old versions of IE.
- Application servers should be able to communicate with the daemon by a
standard, easy to integrate protocol such as HTTP. A simple REST interface
is preferred over XML-RPC or SOAP.
- If in Java, should be possible to compile with Eclipse compiler and run
with GNU Classpath and an open-source VM, even if we use another VM in
production for performance preferences.
I'd like to see also:
- Better control over output format (grayscale staying grayscale, avoiding
wasted bandwidth etc)
- If possible, 'safe' memory usage for resizes of large PNGs as well as JPEGs.
Loading a 10kx10k pixel bitmap into memory to make a 100x100 thumbnail doesn't always end well.
- Other file formats welcome.
There are two main possibilities for data transfer:
- POST an upload of the source file, and receive the data back. MediaWiki
will deal with reading the file from disk and saving the thumbnail back.
- Send and receive pathnames (or partial pathnames). Daemon will handle
disk access, and simply return a file references.
The path references are likely more efficient, but may require sanitizing
for safety.
Version: unspecified
Severity: normal