Marco Schuster wrote:
What about video files exploiting some new 0day exploit in a video input format? The Wikimedia transcoding servers *must* be totally separated from the other WM servers to prevent 0wnage or a site-wide hack.
That's not different than a 0day on tiff or djvu. You can do privilege separation, communicate using only pipes...
About users who run encoding chunks - they have to get a full installation of decoders and stuff, which also has to be kept up to date (and if the clients run in different countries - there are patents and other legal stuff to take care of!); also, the clients must be protected from getting infected chunks so they do not get 0wned by content wikimedia gave to them (imagine the press headlines)...
The exploit affecting third party seems is imho a bigger concern than affecting wmf servers. The servers can be protected better than the users systems. And infecting your users is a Really Bad Thing (tm).
Regarding an up-to-date install, the task can include the minimum version to run it, to avoid running tasks on outdated systems. Although you can only do that if you provide the whole framework, whereas for patents and licenes issues it would be preferable to let the users get the codecs themselves.
I'd actually be interested how YouTube and the other video hosters protect themselves against hacker threats - did they code totally new de/en-coders?
That would be even more risky than using existing, tested (de|en)coders.