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