Is it worth updating https://www.mediawiki.org/wiki/Manual:Extension.json/Schema#requires with the special case for non-extension registered extensions?

@Harej - I believe @Bawolff currently has this assigned as a lower-priority review. Maybe we can address two things:

1. Have all of the issue from his initial review (T201492#4587298) been addressed and resolved or marked WONTFIX? I see some subtasks above - a few of them are resolved w/ corresponding gerrit patch sets, but some still seem open. I'm not sure if that's all of them though.
2. Is there a more firm date you have in mind for production testing or a deploy? If so, we should note that here, as it will help us with our scheduling.

Thanks.

Er, I think I fixed the array() => [] issues in F28682008. Anyhow, I'll plan to make this task public today, push a patch set up to gerrit and work on some tests.

"Rebased" @Bawolff's 3+ year-old patch (T25227#2013640) on master, tested locally. Talked about this with the Security-Team today - fine with just pushing it publicly in gerrit. If there are no objections, I'll create a patch set from the attached: F28682008.

Cherry-picked to 2.x, original patch to master abandoned. Resolving for now.

@WMDE-leszek - just wanted to check and see if there's any working local development environment for this (Vagrant roles, Docker, wikibase-docker w/ additional config instructions, etc.) It's probably not critical for this review, but it would be more helpful than playing around with the wikidata.beta.wmflabs.org example. Thanks.

@JTannerWMF, @kostajh, @Catrope - the Security-Team just had a chat about this. We're fine with the Special:Impact administrative view by itself. We will classify that as an "informational" risk, which wouldn't require an entry within our risk register. If/when the Growth Team is ready to proceed with the administrative view of the Special:Homepage feature (as initially proposed) we can pick up where we left off on that specific feature. If this sounds good and there are no further questions from the Growth Team on this, I can go ahead and resolve this task.

Going to make an executive decision here and resolve this for now. Plenty of other related bugs are open for ongoing issues.

@JTannerWMF - just to clarify your first bullet point - "The Task recommendation module is being put on hold and should NOT be considered for this release", correct?

@daniel- done.

@daniel - per this comment, is there a documented definition of "official WMF tool" anywhere? Specifically, who makes that determination?

@daniel - per this comment, is there a documented definition of "official WMF tool" anywhere? Specifically, who makes that determination?

So this should probably work for now:

@Aklapper - Yeah, that's fine. Our workboards for Security-Team-Reviews and Security-Team-Review-Active default to only show open tasks (I believe - or at least that's my default) which is a perfectly acceptable solution.

@Legoktm - should be fixed. And here.

@Aklapper - Our standard has been to remove Security-Team-Reviews (or Security-Team-Review-Active) when we close a request as declined or invalid, since those projects represent requests that will actually be reviewed at some point. I suppose it doesn't really matter, since any closed task is set to disappear from those workboards, which is the important piece.

@Ramsey-WMF - Ok, thanks for the follow-up. I'll go ahead and close this as declined for now.

Is it helpful to see a bunch of failed instances of composer-package-php70-docker? I'm not sure how valuable that information would be. And the thought here would be to eventually use the composer-package-php7(2|3)-docker whenever we're ready.

@Daimona - sounds good. Also, we're planning to disable composer-package-php70-docker for the 2.0.0 branch.

Hey Multimedia Team. We have this long-lingering review of an old Google-Summer-of-Code project where we'd been asked to review the indigo-depict dependency. Given the elapsed time here and that there most likely isn't a current champion of this extension (as a code steward or for production deployment) the Security-Team would like to propose closing this as declined by April 15th, 2019. If the above assumptions are incorrect and the Multimedia Team (or another team/individual) would like to become a steward for this extension with the goal of deploying to production over the next quarter or two, we can definitely see where we're and reschedule this review. Thanks.

@Daimona - @Bawolff and I created a 2.0.0 branch from master just now for development of new versions of the SecurityCheckPlugin that leverage PluginV2 and newer versions of PHP and Phan.

Sorry for the crazy delay on this, but this extension looks fine to me. Some phpcs issues came up during my review, but they aren't security-related, so I was going to let you review those in CI, etc. Let me know if you have any other questions, etc. Thanks.

@MMiller_WMF, @JTannerWMF - the Security-Team discussed this today. We had a couple of initial questions for you:

Excellent, looks good to me. Thanks.

Patch for review. Feel free to abandon if we want to leave this as an exercise for new mw developers.

@zhuyifei1999 @Framawiki - any update on this? Can we set a date/time to deploy the patch to quarry and backport to gerrit? Happy to help, though I don't currently have access to the quarry project.

Closing as invalid as neither of the URLs mentioned within the description exist anymore and this doesn't appear to have been much of a security concern to begin with.

Great, thanks for the update @WMDE-leszek. I'll target the completion of this review to happen before the 2019-04-30 date. And yes, any updates here as to when SRE can handle the deploy would be great.

Hey @kostajh - just to follow up on this a bit more, I'd like to propose this to the Security-Team and provide a concept review. This will probably involve some measurement of risk for the "view another user's homepage" feature (based upon @Bawolff's concerns and any other potential issues) and the ownership of said risk by the growth team.

@Eevans, @Clarakosi - Thanks for the review request. Given that golang is a little outside of our typical mw core/extensions and web application reviews, the Security-Team will need to think about what will be the best solution for this request. It may end up being a combination of a more focused internal review (centered around static analysis) with the potential for an additional external/vendor review. We'll keep you posted.

@WMDE-leszek Sorry for the lack of updates on this. Do we an updated deployment date for this? I know that had changed since this task was created. I've had a basic look at the code, but haven't completed a full review yet. If we can assign an updated deployment date for this, the Security-Team can establish a more accurate due date for the security review deliverable. Thanks.

On agenda for 4/9/2019 security team meeting.