I think I have added all the relevant tasks as blockers. If I missed any, please add it.

I'm still polishing details and reviewing all the comments in the tasks related. Is there any feature missing? Any detail misunderstood?

Users in the security group should be able to add external users. External users CCed not being able to add other external users is fine (right?)

No. Like with bugzilla, cc'ed users should be able to edit and add more users.

Security extension strips any users CCed manually?

I'm pretty sure this is incorrect. The policy / extension / enforcement / whatever-they're-called strips anyone except the original reported who was added to the "Visible by" and "Editable by" policies. CC's are left in tact, leading to the further undesirable issue that those users are CC'ed when the bug changes, but they are not in the ACL, so they can't view the actual bug.

Thumbnails of private images should be private

...

Maybe yes?

No, not happy with the current situation. We accept the performance hit of checking permissions when accessing images (including thumbnails) on office wiki. For the number of users we're dealing with in Phab, I'm sure we can make it work.

For the number of users we're dealing with in Phab, I'm sure we can make it work.

This is possible without taking the performance hit on public files by checking at page output time (you need to already do that for the task itself) (and at file upload time and permission change time). Then deliver non-public files/images from a URL that checks permission and the public image from a different URL that does not check. That way it even works when a CDN is in use. Only non-public files then either don't use the CDN or use the access control or access token feature of the CDN.

@JanZerebecki & @csteipp: Although you are right, it is possible to differentiate at page output to differentiate between private and public files, it's not really possible without some fairly complicated changes to phabricator code.

There are two issues with this:

1. Development time/budget: Obviously this would take some time and my time is about to go back to release engineering, which is the job I was hired for and have been neglecting so far due to phabricator tasks taking up 100% of my time.
2. Ongoing maintenance / upstream acceptance: Although I believe the upstream phabricator project would accept a patch from us to improve the security of uploaded files, the implementation would have to be something that @epriestley is happy with and fits within the phabricator architecture. If we hack something together that works for us but isn't architecturally correct then we will be stuck maintaining it as a fork of phabricator. Any forked code that we take on will turn into long-term technical debt that we are trying to avoid as much as possible.

Please, let's keep this task focused on "Short term plan for security and private tasks". The thumbnailing problem should be discussed in {T75774}.

Does anyone have a plausible scenario in which a 280x210 thumbnail of an image (which is the largest we'll generate) which requires a long, secret key to access is the failure that allows an undesired disclosure?

Particularly, @JanZerebecki seems to imply (above) that it's OK if a public URI exists, just not OK for it to be used on the task.

It's not particularly difficult to take the performance hit on thumbnails, but I can't come up with a plausible scenario where this matters, and it's slightly simpler to treat all thumbnails uniformly.

Reminder when you write stuff that's more than just a link: This is a public task.

Regarding {T75774}, I have pasted the full list of items there and I prefer to leave judging whether one creates a problem to Chris. Let's please discuss T75774 in T75774 if possible (though T518 might make that harder). Thanks for your understanding.

Today we have Wikimedia Phabricator team meeting. We will go through the table of features above with the goal of being on the same page the four of us. Then we will schedule a meeting with @csteipp (and whoever else is needed) for next week with the goal of agreeing on the plan.

@chasemp wrote the very useful https://www.mediawiki.org/wiki/Phabricator/Security document. I'm going to update the related tasks accordingly and I ill update the bale above.

All in all it looks like we have broad agreement and a short term solution for the CC users problem. More to be discussed in T518.

Currently there is no agreement on the thumbnails of private files. After our Wikimedia Phabricator meeting yesterday, the team has now a commo opinion that I will discuss with @csteipp and whoever else needs to be in the loop. Either we all agree that the current situation is good (our preferred option, backed by the upstream plan and industry practices), or we need to plan and resource a patch that might or might not be taken upstream.

The rest seems to be all good, or just minor details that can be addressed with normal priority.