It requires a *.tools.wmflabs.org ssl certificate, but otherwise there's no technical reason why this would not be possible.

As for other (non-tools.wmflabs.org) domains -- that's somewhat more involved, because it requires more than a single new certificate. See T122403 for that.

In T125589#1991932, @valhallasw wrote:

It requires a *.tools.wmflabs.org ssl certificate, but otherwise there's no technical reason why this would not be possible.

As for other (non-tools.wmflabs.org) domains -- that's somewhat more involved, because it requires more than a single new certificate. See T122403 for that.

I think tools is the project where this sort of thing would get the most benefit.

The only problem would be that we already have advertised in some places login.tools.wmflabs.org, but that can be moved.

I'll put in a procurement ticket for a new *. ssl cert.

I think many (most?) tools are not coded in a way that they can be served from https://$tool.tools.wmflabs.org/ and https://tools.wmflabs.org/$tool/ at the same time, and I think that is impossible to correctly automatically map one to the other (e. g. fixing absolute links in the served pages themselves as well).

So if we go down this road, webservice should have a new option --with-subdomain (or a better name) that sets a flag in the proxy forward entry and the service.manifest file and uses a lighttpd configuration, etc. that expects subdomain URLs. The proxy would implement the logic:

• https://tools.wmflabs.org/$tool/$path:
  • If --with-subdomain is set for $tool:
    • Redirect permanently to https://$tool.wmflabs.org/$path with an explanation why.
  • Else:
    • Serve as usual.
• https://$tool.wmflabs.org/$path:
  • If --with-subdomain is set for $tool:
    • Serve as (then) usual.
  • Else:
    • Return an error page with information for maintainers on how to enable subdomain hosting for their tool.

We could potentially:

• redirect //tools.wmflabs.org/$tool/$path to //$tool.tools.wmflabs.org/$tool/$path,
• redirect //$tool.tools.wmflabs.org to //$tool.tools.wmflabs.org//$tool.

unless some flag is specified, but I'm also fine with making it fully opt-in.

I do remember thinking about this last night/this morning and finding another issue that needed to be addressed, but I forgot what the issue was :-(. I believe it was something in the direction of Cross-origin resource sharing, i. e. if there are gadgets, etc. on wikis that are configured to be able to interact with tools.wmflabs.org, but not necessarily *.tools.wmflabs.org.

In T125589#1992011, @yuvipanda wrote:

The only problem would be that we already have advertised in some places login.tools.wmflabs.org, but that can be moved.

Also checker.tools.wmflabs.org.

We own the domain toolforge.org and moving to that may be easier than using the existing tools.wmflabs.org root. Let's Encrypt wildcard certs are possible now: https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579

I would be very interested in a project to figure out how to use $TOOL.toolforge.org as the default hostname for webservices exposed from the Toolforge Kubernetes cluster. This could give us a chance to implement a better ingress for the cluster, make TLS required (T102367), and fix the URL namespacing issue all together.

May I suggest that the priority of this task be increased somewhat? Without going into too much detail – until this task is fixed, no Toolforge tool can fully protect itself against attacks from other tools. (Sufficiently privileged users can see e. g. T211424 for some more details on possible attacks, though I doubt it’s the only relevant task.)

As a tool author, I would already be very happy with a purely opt-in solution, and we can worry about making it the default for Kubernetes-hosted tools, requiring TLS, etc. later.

In T125589#4854125, @LucasWerkmeister wrote:

Sufficiently privileged users can see e. g. T211424 for some more details on possible attacks, though I doubt it’s the only relevant task.

If I guessed what T211424 is about correctly, T157450 should describe the somewhat-general case. It's linked as the parent task of this task.

Are we supposed to have a CNAME of *.tools.wmflabs.org, or are we going to assign each tool's DNS entries individually? I think after DNS works, we can start playing with domainproxy and see how that will work.

Yep, that’s the same case (thanks for adding me as a subscriber). Good to know that this issue isn’t “lowest” priority because the ramifications were unknown, but rather in spite of them being known for years…

I think a record for *.tools.wmflabs.org (or *.toolforge.org, to avoid conflicts with login.tools.wmflabs.org and other existing subdomains) would be enough, there’s no need to make the (non-)existence of a tool known via DNS IMHO. But I’m not sure why you’re suggesting a CNAME record – should tools.wmflabs.org be the canonical name?

Ping on this one again, and I see action going on at https://phabricator.wikimedia.org/T215531 which is great! However, do we have an approximate ETA on when we would finish the migration ?

In T125589#5669714, @01tonythomas wrote:

Ping on this one again, and I see action going on at https://phabricator.wikimedia.org/T215531 which is great! However, do we have an approximate ETA on when we would finish the migration ?

Per https://www.mediawiki.org/wiki/Wikimedia_Technology/Goals/2019-20_Q2#Technical_Engagement -- we are hoping to have a new Kubernetes cluster deployed in Toolforge on or before 2019-12-31. Full migration of existing workloads to this cluster and removal of the legacy cluster will follow in FY19/20 Q3 (2020-01-01 - 2020-03-31). Giving a more concrete timeline is work that we are tracking in T237784: Document migration plans and timelines.

This is possible now! See https://wikitech.wikimedia.org/wiki/News/Toolforge.org for instructions on migrating your tool during the opt-in period. Follow along on T234617: Toolforge. introduce new domain toolforge.org for further information.