In T266512#6580179, @bd808 wrote:

SBassett is already listed as a maintainer.

@ema - I'll bring it up as a topic at our team meeting on 2020-10-27. Since this would become a new process for the Security-Team to manage, we'd need to work out a few more policy specifics.

@MSantos:

1. Are there major technical reasons why the deployment-mediawiki instance can't support TLS connections? Given T235411, it will likely have to at some point, no? Unless no other services use beta in this way and never will.
2. I'd agree that implementing authentication for option 3 is likely a good idea as an extra layer of security, despite internal-only rest requests hopefully being pretty safe. PKI is the most standard way of doing this over potentially-unencrypted channels, even if it seems a bit heavy in this case. I suppose a shared secret could also work, perhaps as an hmac transaction, but that would be less secure and involve more consideration of replay attacks, time-based expirations, etc.

Hey @Niedzielski - I just wanted to check in and see if there are any updates on desired deployment dates. I still plan to finish this review sometime this month, but was to hoping to maybe set a more specific date/time based on your current estimates. Thanks.

In T265923#6562391, @Aklapper wrote:

In T265923#6562372, @Reedy wrote:

Is there any point changing the email of the account?

I don't think so - it can be invalid and whatever. See also https://www.mediawiki.org/wiki/Phabricator/Bots#Acquiring_a_bot

In T265440#6561393, @SamanthaNguyen wrote:

@sbassett Thanks for clearing that up. And yeah I'm not sure, it looks like I'm still not able to see the task unfortunately?

@SamanthaNguyen - Ok, I've resolved this task and made it public. T263810 is just the tracking task for the quarterly-ish supplemental exts/skins announcement (recent example: https://lists.wikimedia.org/pipermail/wikitech-l/2020-September/093904.html). I subbed you to the task, but perhaps that's not enough to override the current security setting.

@Krd - you are now added. Resolving this task for now.

Thanks, @MoritzMuehlenhoff. I think we just have the two open subtasks left and then we can close this out.

@SamanthaNguyen - I'm not seeing anything on the task that would necessitate this remaining private, so we can make it public if you'd like, just let us know (if you don't have permissions to do so). Also, we can track this at T263810 for increased visibility if you'd like.

Ok, thanks for the update, @Pginer-WMF. I'm going to stall this task for now and drop it into our backlog for the time being. If you or one of the developers can ping me on-task sometime by the middle or end of November, signaling when significant development has been completed, we can agree to some commit shas as a freezing point and a more specific timeline for the review to be completed.

In T265606#6546781, @Urbanecm wrote:

This was caused by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/494638, and merely reverting that patch should fix this.

@Pginer-WMF - this review is technically in progress. Is there a specific date you're targeting for deployment in October?

In T154133#2902770, @Krenair wrote:

If it were, I imagine upstream would find a way to break this as, as far as I know, they don't allow an object's project list to change visibility policy.

All - it appears the ordering stems from an edit about 4 years ago, quite a bit prior to several changes which were made to our security readiness review service, currently governed by this SOP. I'm going to try out an edit for the Preparing for deployment section which changes the list to a <ul>, removes the security review beta deployment "requirement" and attempts to provide a few additional, helpful notes.

@Dzahn - ah, I forgot about that. Thanks. I'll plan to reach out to OIT.

@MoritzMuehlenhoff - I'll plan to follow up on that group and any other security-related ones that I find. Thanks.

In T260466#6530461, @DannyS712 wrote:

Per https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Performance_Review, the prerequesite for a performance review is deployment to the beta cluster. Deployment to the beta cluster is dependent on the security review, thus until this security review is completed the performance review cannot begin. This is also the order used at https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment#Preparing_for_deployment

In T260466#6530443, @Niharika wrote:

Hi @sbassett. We do not have WMF team as steward. However, @MusikAnimal, me and some others are willing to help out in our volunteer time. There is a well-known demand for the GlobalWatchlist extension - both from the community and staff. In an ideal world teams would have some operating capacity to support the incredible work our volunteers do. However given the existing workload our teams operate under, it is highly unlikely that any team would want to pick up the extra work of shepherding this through.

In T260466#6530313, @DannyS712 wrote:

The performance review is usually done after the security review

In T260466#6529944, @Urbanecm wrote:

Thanks. I don't understand why a WMF steward is necessary though

@Urbanecm - based upon the comments starting at T260860#6523535, at the very least we'd need to see a solution for T264833 before any security review commenced, since that blocks deployment of the extension. Have we also confirmed a Foundation-based steward of the code? Is Community-Tech or Anti-Harassment filling that capacity, @Niharika?

Due to commit 8b754f, the stopMobileRedirect cookie wouldn't be sent to servers without HTTPS

In T262628#6516511, @thiemowmde wrote:

Thanks a lot for the detailed response. I'm still curious what "requesting a CVE" means, but understand it's not something my team is asked to do. :-)

@WDoranWMF et al - Sorry for the delay on acknowledging this. I've added an entry within our risk register for your acceptance at T261696#6450752. I went with medium risk for now, since https://gerrit.wikimedia.org/r/621900 is a bit less granular (even if it may currently be restricted within production for a specific use case) that what I had discussed at T261358#6424759.

@ArielGlenn - There is an internal draft policy (I just gave you access) which I feel is mostly complete save clarification on a couple of the actual technical controls and processes. This needs some push from the Security-Team but I believe it is considered fairly low priority for us at this time.