Page MenuHomePhabricator

Add examples of the three security review processes
Closed, InvalidPublic



Wikimedia Security Team/Security reviews lists three separate processes which are either recommended or required in order to get an extension deployed on Wikimedia servers.

For non-WMF developers it can be unclear what is needed for each review step and how the Security team expects the information to be presented.

Who would benefit

  • Anyone unfamiliar with the current review practices, likely meaning extension developers outside of the WMF.
  • The security team: Clearer expectations/instructions should hopefully help streamline new external review requests.

Proposed solution

Identify one or a few good real-life examples for each process (or at least the latter two) to promote as case studies.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 31 2017, 9:15 AM
Lokal_Profil updated the task description. (Show Details)Jan 31 2017, 9:17 AM

(For the records, the entire process to get an extension deployed is at as it's more than just Security.)

Can you be more specific about what you find confusing? The instructions state clearly that only the last one is required (in practise most projects only do the last one. I guess things have to be required to actually happen...)

Anyways, the first two are meant to be somewhat informal meetings where we just check you are on the right track. The concept review would be just to make sure your concept is sane. For example, if your proposal is to allow raw javascript on all pages, we would like to veto that right at the beginning. The design review is meant as a quick check-in to make sure your implementation plan is sane and to be able to make any suggestions. Its always best if we can give feedback early in the process.

The review for deployment is the formal review. Your extension should be done at this point, and we check it carefully. For examples of this look at the done column of Security Readiness Reviews as well as tasks with that tag that are resolved fixed.


I've attempted to flesh out the docs on wiki. Does that clarify things? Or are they still confusing?

Tgr added a subscriber: Tgr.Feb 3 2017, 8:42 AM

@Lokal_Profil can this be resolved or is there something you are still missing from the documentation?

Qgil added a subscriber: Qgil.Feb 3 2017, 4:03 PM

In case of doubt I would add this request to Developer-Wishlist (2017). The "worst" case scenario would be that the task is solved by the time it is voted. Not a bad problem to have. :)

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Thanks for the examples on the security review part. For me these are enough for that section.

The "Design review" section could still benefit from a few examples especially since it seems to normally consist of a more informal in-house meeting (or that is the outside impression at least). As such it is harder for someone outside of the WMF to figure out which documents they need to have prepared before etc. And examples bring this across better than just terminology.

To be honest, I think the "security design review" is more wishful thinking then actual practice. I don't think most projects actually undergo it.

If you're doing something relatively different from the average mediawiki extension, having a document saying this is what we want to do, and this is in broad strokes how we're going to implement it, would probably be useful. From your perspective, you probably want to tell us enough details so that if there is something to object to, we can object before you spend time doing it, not after. [I know that's not terribly helpful...]

Qgil removed a subscriber: Qgil.Feb 15 2017, 2:59 PM
chasemp moved this task from Incoming to Back Orders on the Security-Team board.
chasemp triaged this task as Medium priority.Dec 23 2019, 5:19 PM
chasemp moved this task from Back Orders to Watching on the Security-Team board.
chasemp moved this task from Incoming to Back Orders on the Security Readiness Reviews board.
sbassett closed this task as Invalid.Thu, Jan 9, 3:21 PM
sbassett moved this task from Back Orders to Our Part Is Done on the Security Readiness Reviews board.
sbassett added a subscriber: sbassett.

I'm going to close this task as invalid for now, since the above discussions were related to a completely different set of security review policies which were superseded by a new SOP in February of 2019. The current SOP has continued to evolve and will likely evolve further as the Security-Team is in the process of revamping some of our intakes and workflows, which should hopefully wrap up Q3 of FY 2020. If there are still concerns over the current SOP, I would invite folks to first contribute their concerns on its talk page to keep pre-actionable discussion in a single, logical place.