dzahn wrote on 2014-08-28 01:29:18 (UTC)

and i would request *.wmfusercontent.org right away, i _think_ we want a unified one in this case, not a separate one for each service to come. that being said, if we actually kill BZ, what else IS going to use it? technically, lists.wm allows users to upload stuff

So I propose to uninstall Files and open LDAP. The only reason to keep LDAP closed is that we don't want people to upoload files, right?

In T373#5, @Qgil wrote:

So I propose to uninstall Files

We cannot --- "This application is required for Phabricator to operate, so all users must have access to it."

Drifting from "certificate"-only topic into general "separate server for attachments and setting that up" land.
Status summary, as far as I understand it:

• Registering wmfusercontent.org (https://rt.wikimedia.org/Ticket/Display.html?id=8161) is closed as resolved, and it's also in our DNS already.
• The procurement ticket for the purchase of the certificate is closed as resolved: https://rt.wikimedia.org/Ticket/Display.html?id=8212
• Setting up the multiple certs on nginx on the misc varnish cluster / Set up SNI on misc-web-lb (https://rt.wikimedia.org/Ticket/Display.html?id=8345) is also resolved, but according to Mark's comment from last week "The backend of this hasn't been deployed yet, so more Varnish and Apache work is needed for Phabricator, but I believe that is outside the scope of this ticket." There's not an RT ticket to follow for every related task (overhead) so it's not entirely clear from the outside where we're at. After above comment these followup patches exist(ed) which I am aware of:
  • https://gerrit.wikimedia.org/r/#/c/161200/
  • https://gerrit.wikimedia.org/r/#/c/161355/ https://gerrit.wikimedia.org/r/#/c/161356/
  • https://gerrit.wikimedia.org/r/#/c/161357/ https://gerrit.wikimedia.org/r/#/c/161358/ https://gerrit.wikimedia.org/r/#/c/161389/
  • I assume the outstanding next patch is: https://gerrit.wikimedia.org/r/#/c/161180/

I've asked Mark on IRC today: He wrote that "the nginx stuff is all done, sni/nginx that is. i finished that on thursday last week. but there's no backend setup for it yet that I'm aware of".

Backend setup "means, a web server vhost on the phabricator needs to be setup for it that varnish will talk to
and phabricator needs to be configured for it
and it all depends on how phabricator handles that
so yeah, we could do that, but i have no idea if that'd be consistent with the plans for it, and given that there are security implications of it all
i'd rather not guess and wait a few days until Chase can work it out"

I don't understand the last few comments here.

The cert is installed and working. check yourself whether you get any SSL/TLS related errors in your browser at https://phab.wmfusercontent.org/

The server sends an error message (after client successfully authenticates the server unless client has some non-standard root CA store):
[Core Exception/Exception] Specified domain phab.wmfusercontent.org is not configured for Phabricator requests. Please use https://phabricator.wikimedia.org to visit this instance.

That indicates to me that all further work to get that domain working for uploads is on iridium (and manifests thereof), not varnish/nginx/etc. (and I *think* I saw the same error message before T373#17 so this was already fixed by then)

I don't see any upload tickets related to this one. So morph into fixing the iridium conf or make a new one?

In T373#22, @jeremyb wrote:

I don't understand the last few comments here.

(snip)

I don't see any upload tickets related to this one. So morph into fixing the iridium conf or make a new one?

I don't know enough about the problem to create a new task, and I'm fine reusing this one after the actual problem is solved: users being able to upload files securely in phabricator.wikimedia.org.

to clarify and ensure we're all on the same page:

the security blocker for T463: Enable registration for everybody at phabricator.wikimedia.org is not securing the process of uploading, (which is what I think when I read "users being able to upload files securely"). the issue is that after upload is done, uploaded content that's available for download must be prevented from escalating uploader's access to a different user's phab session. this is done by making those downloads come from a different origin (in this case even a different effective second-level domain).

@jeremyb, you are correct.

This should be done.

See: https://phab.wmfusercontent.org/file/data/ihuof2rmdriw7d2exu6c/PHID-FILE-sijhbkzgwmbxorrnrzpb/3ijsborvmimauuxp/aiOZA8rh.jpg

LGTM!