2010/10/25 Brion Vibber<brion(a)pobox.com>om>:
In all cases we have the worry that if we allow
uploading those funky
formats, we'll either a) end up with malicious files or b) end up with lazy
people using and uploading non-free editing formats when we'd prefer them to
use freely editable formats. I'm not sure I like the idea of using admin
powers to control being able to upload those, though; bottlenecking content
reviews as a strict requirement can be problematic on its own.
Yeah, I don't
like the bottleneck approach either, but in the absence
of better systems, it may be the best way to go as an immediate
solution. We could do it for a list of whitelisted open formats that
are requested by the community. And we'd see from usage which file
types we need to prioritize proper support/security checks for.
What I'd probably like to see is a more
wide-open allowal of arbitrary
'source files' which can be uploaded as attachments to standalone files. We
could give them more limited access: download only, no inline viewing, only
allowed if DLs are on separate safe domain, etc.
It seems fairly straightforward
to me to say: "These free file formats
are permitted to be uploaded. We haven't developed fully sophisticated
security checks for them yet, so we're asking trusted users to do
basic sanity checks until we've developed automatic checks." We can
then prod people to convert any proprietary formats into free ones
that are on that whitelist. And if they're free formats, I'm not sure
why they shouldn't be first-class citizens -- as Michael mentioned,
that makes it possible to plop in custom handlers at a later time. A
COLLADA handler for 3D files may seem like a remote possibility, but
it's certainly within the realm of sanity. ZIP files would have to be
specially treated so they're only allowed if they contain only files
in permitted formats.
So, consistent with Michael's suggestion, we could define a
'restricted-upload' right, initially given to admins only but possibly
expanded to other users, which would allow files from the "potentially
insecure" list of extensions to be uploaded, and for ZIP files, would
ensure that only accepted file types are contained within the archive.
The resultant review bottleneck would simply be a reflection that we
haven't gotten around to adding proper support for these file types
yet. On the plus side, we could add restricted upload support for new
open formats as soon as there's consensus to do so.
The main downside I would see is that users might end up being
confused why these files get uploaded. To mitigate this, we could add
a "This file has a restricted filetype. Files of this type can
currently only be uploaded by administrators for security reasons"
note on file description pages.
ODS, ODT and such should be fairly easy to check at least on a basic
level. A very basic check would be to check if it contains "Basic" or
"Scripts" folder. Bit more advanced would be to check if manifest.xml
contains "application/binary" (to check if anyone tried to change
default naming) and check if any file contains "<script:module" (for the
If any of this would be true than there should be a warning.
I think we should also support Dia for diagrams and XCF for layered
bitmaps. Don't know much about XCF, but Dia is a simple XML file (which
might be zipped) and so shouldn't be dangerous at all. I guess it could
even be unzipped upon loading because Dia supports both zipped and
unzipped versions alike. There is/was also Extension:Dia which generates
thumbnails... It seems to work fine even with 1.16 from the trunk and
the latest Dia version. It doesn't work with zipped Dia files but this
would be manageable.