@2010-10-26 03:45, Erik Moeller: > 2010/10/25 Brion Vibber<br...@pobox.com>: >> 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 same reason). 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. Regards, Nux. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
