Wikitech-l February 2019

wikitech-l@lists.wikimedia.org

56 participants
63 discussions

Plugin to mention/reference Phabricator ticket IDs on Gerrit (as comments) to Phabricator
by Derick Alangi 01 Feb '19

01 Feb '19

Hi, I'm not sure if this tool already exist but I'm wondering if there is a Gerrit plugin that provides a feature for mentioning a Phabricator ticket on a Gerrit change set and this reveals on the Phabricator ticket itself like what happens Phab - Phab tickets; Process: We have Gerrit patch A and Phabricator ticket T -> comment on patch A in gerrit with ID of T -> Check T (on phabricator) and should see a message saying "mentioned in patch A (with a link embedded to view patch on gerrit directly). I would really love this feature as sometimes bugs are fixed and not referenced so just dropping a comment to the patch (after maybe the patch has been merged) with the ticket ID should mention it on phab. Or sometimes some builds fail for some reasons and mentioning the ticket id on the patch should mention this on phabricator for reference, there are many use cases but these are just a few. Cc @Paladox Thanks :) *--* *Derick* >

2 2

IE 6/7 MIME type sniffing checks on uploads - is it time to retire them?
by Brion Vibber 01 Feb '19

01 Feb '19

There's been some comments on some old tasks such as T27707 <https://phabricator.wikimedia.org/T27707> about problems with uploading files that include text metadata that looks like HTML elements. Years ago, we added security checks for IE 5/6/7 to work around IE's mime type sniffing: if you went to view a .png file directly in IE (as opposed to in an <img>) the browser would check the first few bytes of the file to detect its type, overriding the HTTP Content-Type header. HTML would be detected with a higher priority than the actual image formats, making it possible to create an actual .png image which when viewed as an image looked like an image, but when viewed as a web page was interpreted as HTML, including any embedded JavaScript. (This was defense in depth in addition to hosting files on a separate domain; among other things, we sometimes serve files out from the main domain when dealing with archived (deleted) versions, and third-party installs are not guaranteed to have a second domain.) Browsers have moved on, but the code remains and it trips up legitimate files containing links in metadata, or sometimes just random compressed data that looks like an element! I've done a quick research check on feasibility: * IE 6 and earlier can no longer access Wikimedia sites due to lack of SNI and TLS 1.0 or later * IE 7 on Windows XP can no longer access Wikimedia sites due to lack of SNI * IE 7 on Windows Vista **can** access Wikimedia sites. * IE 8 and higher support X-Content-Options: nosniff to disable sniffing, which we already use on all MediaWiki requests. At some point Microsoft dropped the sniffing, but I'm not sure if it was a later IE version or an Edge version. No other browsers in reasonably current versions seem to have this problem. So the only remaining browser version that might be affected is IE 7 on Windows Vista, which supports SNI and TLS 1.0. It might or might not still work once we drop TLS 1.0 some time in the future. (Per our TLS dashboard <https://grafana.wikimedia.org/d/000000458/tls-ciphersuite-explorer?orgId=1> about 1.2% of our connections still use TLS 1.0, but this isn't broken down between logged-in-user views and anon views.) Open questions: * Should we drop the anti-sniff checks on upload? * If we do, should we forbid logins with IE 7, or something else to protect the occasional IE 7 logged-in user from a hypothetical targeted drive-by attack? (Is it actually worth doing work and testing it for this?) * Should we add X-Content-Options: nosniff on files served from upload.wikimedia.org too? -- brion

2 2

Phabricator monthly statistics - 2019-01
by communitymetrics＠wikimedia.org 01 Feb '19

01 Feb '19

Hi Community Metrics team, This is your automatic monthly Phabricator statistics mail. Accounts created in (2019-01): 364 Active Maniphest users (any activity) in (2019-01): 936 Task authors in (2019-01): 528 Users who have closed tasks in (2019-01): 295 Projects which had at least one task moved from one column to another on their workboard in (2019-01): 300 Tasks created in (2019-01): 2312 Tasks closed in (2019-01): 2112 Open and stalled tasks in total: 40654 Median age in days of open tasks by priority: Unbreak now: 14 Needs Triage: 470 High: 824 Normal: 1042 Low: 1403 Lowest: 1350 (How long tasks have been open, not how long they have had that priority) Active Differential users (any activity) in (2019-01): 18 TODO: Numbers which refer to closed tasks might not be correct, as described in https://phabricator.wikimedia.org/T1003 . Yours sincerely, Fab Rick Aytor (via community_metrics.sh on phab1001 at Fri Feb 1 00:01:08 UTC 2019)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2019