Tue, Oct 27
Mon, Oct 26
Thu, Oct 22
- 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.
- 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.
Tue, Oct 20
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.
Mon, Oct 19
@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.
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.
Fri, Oct 16
Thu, Oct 15
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.
Wed, Oct 14
@Pginer-WMF - this review is technically in progress. Is there a specific date you're targeting for deployment in October?
Tue, Oct 13
Fri, Oct 9
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.
Thu, Oct 8
@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?
Mon, Oct 5
Due to commit 8b754f, the stopMobileRedirect cookie wouldn't be sent to servers without HTTPS
Fri, Oct 2
@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.
Sep 28 2020
@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.