hi Alec,

On Wed, Jun 14, 2017 at 04:12:49PM +0100, Alec Muffett wrote:
> I'd love to know more about the security issues in particular.  Do please
> tell?

I don't recall finding a specific vulnerability, but last time I had a
look at EOTK a while ago, it generated an nginx config that performed a
series of steps to manipulate HTTP headers and body (HTML & Javascript)
using (hard to audit) regexps. This is not a great security practice
IMHO, as it can result in all kinds of unexpected output, especially
with user-controlled untrusted input. It's the kind of thing that has
runs the risk of generating XSS, header CRLF injection vulnerabilities
etc.

More broadly, using regexps to manipulate content means that you either
replace mentions of "upload.wikimedia.org" blindly, even
legitimate/non-href ones like a mention of it in the article text, or
you attempt to parse the syntax of HTML and Javascript with regexps,
including quotes, escape sequences, comments etc. Neither are the right
thing to do.

EOTK as I understand it also pre-generates an nginx config with a very
specific site-specific configuration, such as CSP, TLS ciphers etc.
These may are secure, but are the kind of settings we are paying a close
attention to and manage ourselves, so delegating them to a tool like
EOTK is not something we can do. That said, it may be possible to use
EOTK to bootstrap our configuration and then remove the bits that we
manually manage and care about, so I don't think this is by itself
hindering our usage of it.

> I would love to know more about what you see as the inhibitors - especially
> so that I can go fix them for the internet-community-at-large - however
> this decision is one for the Wikipedia community to take.
> 
> I'll still happily help if you decide "yes", but WMF should make and own
> the decision.

Note that there is a distinction between "the [e.g. English] Wikipedia
community" and the WMF. We are all part of the same movement but the
various wiki communities have decision-making capabilities of their own,
especially when it comes to matters such as who's allowed to edit what,
when and how. Allowing edits over Tor is not the kind of decision the
Foundation can unilaterally make, while setting up the Onion service
would be something that the Foundation would do, since it would just be
part of our infrastructure and thus our mandate.

Granted, serving the site over an Onion service is orthogonal to being
able to edit it, so it's something we may eventually do anyway, even if
the situation around editing remains the same. It does limit its scope
and usefulness though, and is thus a factor that contributes to our
prioritization (or lack thereof).

Best,
Faidon
--
Faidon Liambotis
Principal Engineer, Technical Operations
Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to