I'd like to deploy phabricator upgrade in the near future since there are a lot of really good features introduced since we last updated. The problem is, the upgrade will disable the security extension because the infrastructure it depends on has been removed from upstream phabricator. They didn't kill our feature without consideration, however, on the contrary, @epriestley did a lot of work to support our workflows without the need for any extensions.
**Please take a look**
You can try out the updated code which is currently deployed on https://phab-01.wmflabs.org.
1. Log in (create an account if you haven't used phab-01 before)
2. Click the {icon plus color=blue} icon on the toolbar in the top right of the page.
3. The menu shows a new option labeled `Report Security Issue` which will take you to a new streamlined form to submit a task.
Tasks created through this form will be automatically assigned the appropriate policy. The result should be essentially the same as choosing "software security bug" on our current task submission form.
You'll get a better feel for it if you log in to phab-01, however, pictures are good too:
|{F3288898}|{F3288906}|
---
A lot of discussion has happened in the upstream task, you can read all the details if you'd like more context: https://secure.phabricator.com/T8434
I just don't want to blindside anyone by breaking critical workflows or introducing major changes without much warning.
The only thing that I can think of which might be disrupted is converting a task from public to restricted. Currently that is supported by editing the value of the security field on a task. Without the security extension that won't be an option for most users, only someone with enough privileges to edit task policies will be able to restrict access to a task. How much impact will that have on people's workflows? I don't know if it's common to change a task from public to private. Once a task is submitted as public then it's potentially indexed on public search engines so restricting it after the fact does not prevent it from being seen. To me that limits the value of restricting tasks after they are already made public.
I really don't want to blindside anyone by breaking critical workflows or introducing major changes without much warning, which is why I am submitting this task. I'd like to solicit @csteipp's opinion, along with anyone else who is regularly involved in handling security reports.
IMPORTANT: tldr; Your feedback will be greatly appreciated. If there isn't any objection then I can proceed with deploying these changes next Wednesday during the scheduled deployment window.