Hello all, for some types of resources, it's desirable to upload source files (whether it's Blender, COLLADA, Scribus, EDL, or some other format), so that others can more easily remix and process them. Currently, as far as I know, there's no way to upload these resources to Commons. What would be the arguments against allowing administrators to upload arbitrary ZIP files on Wikimedia Commons, allowing the Commons community to develop policy and process around when such archived resources are appropriate? An alternative, of course, would be to whitelist every possible source format for admins, but it seems to me that it would be a good general policy to not enable additional support for formats that aren't officially supported (reduces confusion among users about what's permitted -- there's only one file format they can't use). Thoughts? Thanks, Erik

On Mon, Oct 25, 2010 at 3:50 PM, Max Semenik <maxsem.wiki(a)gmail.com> wrote: Does that bug even affect Wikimedia? We have uploads segregated on their own domain, where we don't set cookies or do anything else interesting, so what would an uploaded JAR file even do? If that kind of attack is still a problem even with separate domains, we can do like Mozilla's Bugzilla and serve each uploaded file from its own unique domain (that would have ramifications for how browsers fetch the images, but they might be positive anyway).

On Mon, Oct 25, 2010 at 10:09 PM, Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote: upload.wikimedia.org could end up on Google's Safe Surfing (or however it's called) blacklist for hosting malicious .jar's which are injected on another pwned web site or loaded through pwned advertising brokers. Given the fact that Java is the 2nd biggest exploit vector in terms of exploits (but 1st in terms of impact - users don't update Java as often as the Adobe Reader), it should not be allowed to upload JARs (or things that look like something else, but infact can be loaded and executed by the JRT) to Wikipedia. Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Its most ideal if we actually support these formats, so we can do thing like thumbnails, basic meta data etc. Failing that its better to support a given file extension, then it is to support zip files. This way if in 'the future' we add support for X file format, then we have X format files stored consistently so we can support representation of that file format. If we add blanket support for 'throw whatever you want' into a zip file, it will be difficult to give a quality representation of that asset in the future. ( other than as a zip file with multiple sub assets ).

2010/10/25 Brion Vibber<brion(a)pobox.com>om>: 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. 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.

2010/10/25 Brion Vibber <brion(a)pobox.com>om>: 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. 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. -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

[Kicking this thread back to life, full-quoting below only for quick reference.] I've collected some additional notes on this here: http://commons.wikimedia.org/wiki/Commons:Restricted_uploads Would appreciate feedback & will circulate further in the Commons community.

[Kicking this thread back to life, full-quoting below only for quick reference.] I've collected some additional notes on this here: http://commons.wikimedia.org/wiki/Commons:Restricted_uploads Would appreciate feedback & will circulate further in the Commons community. Thanks, Erik