Thanks for the task, but it's very unclear what the problem is, and what you're wanting doing.

Please can you elabourate and clarify? "Write a policy", "Update a policy" or "Review policies" isn't very actionable.

Also, please don't create your own security rules for tasks.

Thanks for the task, but it's very unclear what the problem is, and what you're wanting doing.

As indicated above, if a security concern is raised in an extension, it is usually done so by creating a task on Phabricator only the Security team has access to. This includes the maintainers of the extension: In that particular case, I have not been informed about the issue inside the extension I maintained until it was basically closed, denying me the chance to give input regarding the patch until public disclosure.

In general, I think this is quite problematic. Therefore I propose the security team adds the extension maintainers as part of their policy of handling security reports, since it is the only way I can see to improve this.

As far as I see, this should be a minor change, just an additional point to keep in mind for the future. However, I was given the impression that creating a task in this fashion is the right way to make this request to the security team. I am sorry if I was mistaken.

In T290891#7366292, @Reedy wrote:

Also, please don't create your own security rules for tasks.

I did not and have no permissions to do so. I used the phabricator form provided for a "Security Request For Service". I did not notice this task to have any non-standard security rules until now. From my side, this task may be public.

In T290891#7367269, @MGChecker wrote:

Thanks for the task, but it's very unclear what the problem is, and what you're wanting doing.

As indicated above, if a security concern is raised in an extension, it is usually done so by creating a task on Phabricator only the Security team has access to. This includes the maintainers of the extension: In that particular case, I have not been informed about the issue inside the extension I maintained until it was basically closed, denying me the chance to give input regarding the patch until public disclosure.

But how would anyone know to add you specifically? Where are you marked as a maintainer of the loops extension?

You're a watcher of MediaWiki-extensions-Loops, but anyone can be one, so it's not an indicator.

Neither https://www.mediawiki.org/wiki/Extension:Loops or https://github.com/wikimedia/mediawiki-extensions-Loops/blob/c659d2a/extension.json list you.

https://github.com/wikimedia/mediawiki-extensions-Loops/commits?author=MGChecker shows you have 6 commits, but having commits doesn't (implicitly or explicitly) make you a maintainer either, especially when they're 2.5 years+ old.

I have to admit that I have not been to mindful to making this information more widely accessible. I do not consider myself a real author of the extension, so I have not added my name on the respective places. I have added respective indications now.

Regarding your questions, I have +2 permissions on Gerrit for this repository specifically, as can be seen at https://gerrit.wikimedia.org/r/admin/groups/d88b5dcd1ad4d831c41bec2ef25e781e4ebad87f,members . However, I have to admit that this is not easily accessible.

Extensions like this, which are quite stale, do not really require too regular updates to keep them accessible. I am watching the gerrit projects for input and review patchsets by other contributors – if there would be any.

I have no real qualm regarding this particular incident, however I was concerned whether you have this point on the radar. If you do, that's nice, but I wasn't sure about that.

I will admit I don't really use those gerrit lists for any sort of canonical information. It's buried and not easy to find, or even think of it as anything authorative.

I will note that we do usually try to make sure maintainers are CC'd where we can find the information. For example when we get security bug reports against random Tools, we do try to CC them to the reports (where they have phab accounts, and can match them to the tools lists), and sometimes will redirect reports upstream in some cases.

Same applies for extensions etc or other entities we can try and map to relevant owners.

I'm not going to say this works 100% of the time (some username mappings are non obvious, some people don't have phab accounts), but wrt your point about policies and procedures, I have already documented how to do the lookup of some of this information (especially for Tools) in procedures (not currently public) on how to do the initial triage of security reports.

Thank you, this is everything I asked for! From my side, this can be marked as resolved then.