On May 27, 2014 11:28 PM, "Matthew Flaschen" <[email protected]> wrote: > > On 05/27/2014 09:11 PM, John wrote: >> >> How would this work for non-wmf wikis? > > > It could be configurable, and default to only allowing content under the image upload path on the local wiki (if it's enabled at all). > > >> what about executing JavaScript that is posted to a approved wiki? This would make XSS and a whole host of other >> problems a lot easier to do. So we whitelist commons.wikimedia.org whats >> stopping a user from making a user subpage with some JS code that executes >> something arbitrary? > > > I specifically said bits.wikimedia.org and upload.wikimedia.org (and not commons.wikimedia.org), neither of which host user JavaScript. > > Matt Flaschen > >
Gadgets are on bits and they are user controlled. Ditto for mediawiki:common.js et al. (Unless you mean users as in non admins). I see no usecase from allowing from bits. If someone wants an extension asset they can upload it. Personally i dont understand where this conversation is going why is js even a concern for librsvg. Does it even support that? Surely xss isnt the main concern about fetching random files from the image scalers. Im not really familar with what the threat case is for restricting svgs, but making image scalers not be able to access the wider network seems like it would reduce the attack surface significantly. For the client side of things, i havent looked at svg validation code recently, but dont we have roughly the same security concerns both before and after this? --bawolff _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
