On Thu, Jun 19, 2014 at 11:15 PM, "Christian Müller" cmue81@gmx.de wrote:
Sent: Dienstag, 27. Mai 2014 um 21:21 Uhr From: "Chris Steipp" csteipp@wikimedia.org To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] SVG linking of external images/bitmaps - xlink:href should support http(s) resources On Tue, May 27, 2014 at 9:37 AM, "Christian Müller" cmue81@gmx.de wrote:
[..] Trusting an image library to correctly speak http without a memory corruption seems a little scary as well, but I'll admit I haven't looked at librsvg's code myself.
In any case, it'd be the image library to fix. Restricting access is an arguably crude workaround due to diffuse fears. It breaks the standard and makes technology less useful to its users.
[..], if there are any major browsers that will pull those resources in and let an attacker see the user's IP address, we shouldn't allow that... hmm, and now that I read the bug, I see this is firefox'es behavior in the image you uploaded. We probably want to block that behavior.
Yeah, Firefox's decision to adhere fully to the SVG standard is right imho, since it has to measure itself in compatibility tests with other browsers.
If WP decides to cripple the standard for security reasons, that's their beer, but please stop starting to cripple user browsers. Security of that is in the hand of users, they have to make the decision wich browser to use and whether that ought to be a security enhanced one with less standard compliance, or a full featured one like FF.
I meant that because those browsers are fully implementing the spec, MediaWiki needs to protect our users privacy in case that is used. We have no influence over Firefox development, and I agree, the browsers should implement the spec. We just need to ensure we are taking precautions in that context.
Allowing a whitelist of WMF domains via https may be possible. In general, the security checking we do on uploaded files is complex enough that I don't like adding another layer of specific checks and exceptions, but if we can find a relatively simple way to do it that maintains our security and privacy requirements, then I wouldn't stand in the way.
Ok, within WP scope, hosting external dep files on foreign servers is out of reach, security- and longlivety-wise - it seems everyone agrees on this.
Afai am concerned, two short-term achievable issues remain:
- allow certain WMF domains via https for thumbnail generation and librsvg processing in general - this is to adhere to SVG standard, as long as dependant files remain in wikimedia universe. (Is there a chance for this to make it into 1.24git?)
Like I said, if someone can find a simple way to do this, we can allow it in MediaWiki. If someone wants to work on it, one of the first steps is to get the security/privacy requirements defined (along with the function requirements, like cscott brought up in the reference below). Most have been brought up here or on that bug, but someone should distill those somewhere.
- fixing chunked upload to not bail out on chunks that are exclusively base64 encoded and hence make valid files that include this base64 chunk fail on upload - with an unusable error description.
This will unfortunately require a different approach to how we do stashed/chunked uploads. Currently, each chunk is actually available from the server as a file. So each piece has to be checked for xss vectors, which is why your chunks currently fail. The stash will need to be inaccessible to end users.
Farther off might be the need to rethink part of the file infrastructure, to either broadly allow formats that are not self contained OR make a strong and reasoned decision against that and document it for wikipedians. This has been suggested here: http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076700.html
Regards, Christian
ps:
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l