I *guess* that's about setting up such a dedicated incoming email address on WMF servers, write some script that takes the input and make somehow sure that the custom checkbox for access restriction can be set (I don't know how) and passing that again to Phab (probably via email again to somehow keep the original reporter intact)? Doesn't sound entirely trivial.

Maybe the simplest scenario is to have an email address i.e. security-bugs@, in the lines of T675?

The more I thought about this, the more I don't think this will work. To be effective, we have to publicize the email address heavily (like we do with security@wikimedia.org currently). And on the current account, we get about 50 spam emails / day. I wouldn't like to have to close those every day in Phab.

Quoting https://www.mediawiki.org/wiki/Phabricator/Security#A_direct_way_to_submit_a_security_report_as_a_private_task

• Currently the intention for a few specific projects related to Operations is to route certain emails as bot created tasks from anonymous senders.
• The security transform is applied via the existing and known mechanisms outlined above (using the auxiliary field via task creation with Conduit).
• There is no way to set policy on a task via email.
• There is no way to set policy on a task via project association.

Question: can the Security dropdown option be defined with a URL parameter?

Nope, I don't see the option. FWIW custom fields are handled via conduit with "auxiliary" and this seems not be supported via URL parameter's at all. In theory it wouldn't matter as to adjust policy you need to part of the relevant groups and I don't know if it would die on initial filing policy adjustment or not. I mean technically all tasks have policy, even new tasks filed now by users who can't adjust policy.

Anyways,

https://github.com/wikimedia/phabricator-tools/blob/master/bugzilla_create.py#L285

Not supported via URL atm.

Chad and I tried to get this working with the task templates, but that didn't really work either.

This isn't quite as important as T518, but it is really important that we can give a link to user to file security issues, and not, "click this link, find this dropdown, make sure you select the right one, and if you mess up the issue is permanently public."

Does this mean that we are still stuck with security@ email address?

Also, what about a Phabricator extension to report security issues, consisting of a Create Task form, with the Security configuration predefined as security task, and not visible in the UI?

I don't understand exactly the idea behind the last suggestion there, but the most straightforward thing would be for us to contribute a patch upstream that allows 'auxiliary' to be passed in by URL. That would keep all current abstractions consistent, but allow for embedded links that create appropriate security tasks.

In T76563#825675, @chasemp wrote:

the most straightforward thing would be for us to contribute a patch upstream that allows 'auxiliary' to be passed in by URL. That would keep all current abstractions consistent, but allow for embedded links that create appropriate security tasks.

Sounds good to me.

Adding a dep on T823 as Spaces might solve the "Create Security task by sending an emal to a certain address" part, see https://secure.phabricator.com/T8493#119789

Is this basically resolved by the forms change (@20after4?) at https://phabricator.wikimedia.org/maniphest/task/edit/form/2/ ?

Note also the "Protect as security issue" link in the task menu (Top right of the page) which will convert a regular task into a protected security task.