Phabricator Username: @Zabe
Reasons For Request: I currently help maintaining CentralAuth. I also help general to work on unmaintained deployed extensions. I would like to see related security issues so I can help out fixing them. I have filed a few myself in the past.
I have signed a volunteer NDA as part of T297323. I have 2FA enabled for my phabricator account.
Hi @Zabe! Thanks for reaching out and thank you for everything you do!
One of the first questions that we look at for a request like this - for WMF staff or anyone else - is if there is a need for the person to have access to all of the security-protected content in Phabricator. In other words, does the requestor really need access to everything? The reason why the bar for granting such access is kept high is because many tasks in Phabricator that are protected contain information that is sensitive, or that can be used to cause damage to our systems or disrupt the projects. As such, leadership's direction to us is to keep the number of people who can view those tasks limited to those who must have it.
As for granting you access to all security-protected tasks in Phabricator for now, we must respectfully decline. That is in no way a reflection on you - that is just us adhering to our "need to know" rule for granting this type of access. For granting access to certain individual tasks in Phabricator, the bar can be lower depending on the task. We should have a more granular way to separate the most sensitive security-related content in Phabricator from tasks that we more freely add people to, but we don't have that capability right now and I am not sure when we will. If we can find a way to implement that granularity, I'll reopen this task and reach out to you.
Are there any specific tasks you need access to today?
@Dsharpe: Given that this is a request by a respected contributor in good standing who has +2 rights in Core (T296165), signed an NDA (T297323) to have Logstash access, wrote 415 patches across many codebases (*) in the last 90 days (351 of them merged) and reviewed 290 Gerrit patches (*) in the last 90 days (which both might be more activity than many WMF engineers who have Security ticket access for reasons which sometimes might boil down to "I work here so I'm tasked to work on stuff and you hand out permissions because I work here"), and seeing the numerous lingering open security issues which likely lack human capacity (also due to the nature of restricted access) and lack of prioritizing in WMF's engineering planning, I'm asking you to either please reconsider this decision, or kindly explain which other reasons our few volunteer contributors who have a great cross-codebase understanding of our systems would have to provide. Thanks in advance for considering.
(*) Note that these two links will only start to show results soon, as I just renamed the database entry from a real name (probably indexed from Gerrit) to "Zabe".
Hmm, as a person (one of two or three folks) who helps maintaining CentralAuth, which is reponsible for authentication and authorization on production and has currently no code stewardship, yes imo it would make sence to get access. Security vulnerabilities are sometimes not fixed for a very long time if they are not highly critical.
Random example: T260863: Globally hidden usernames can be enumerated by unauthenticated users by crawling Special:GlobalUserRights with user IDs
^ That issue quite easily allowed generating a list of all globally suppressed users, but no one was around to see that this issue would allow something this severe. Thus, it did not got fixed for 10 months and then it only got fixed because I basically rereported the same issue. Not good.
In T285190#7175269 sbassett told me that there are 'plenty of somewhat dated and forgotten bugs in Phab that deal with similar issues'. That gives me pause. The existence of many partly quite old open sec issues was also meantioned by @Aklapper above.
To be honest, this request is not a rhetorical masterpiece. I would definitely understand if my point wasn't conveyed. CentralAuth is my main motivation here. In addition, there will be similar issues in other extensions, which again like times are not fixed because there are few volunteers with access and it is often not within the purview of WMF/WMDE staff with access.
In other words, does the requestor really need access to everything?
That wording is not good imo. Off course I don't need access to everything, but that applies to (almost) everone. Moreover, whether access to a specific task is needed usually cannot be practically estimated in advance, it would simply be far too much work.
I would also say that the word 'need' is not good itself, especially in the context of a volunteer contributor. This sometimes results in a response that seems a little bit like 'You are doing this in your volunteer time, so you don't need to do this, so you don't need access' (I am not specifically referring to security issue access requests here).
In my opinion, the question that should be asked is if it would be beneficial for the general security of the site to grant access. (Of course, I understand that data protection must not be neglected in the process.)
The reason why the bar for granting such access is kept high is because many tasks in Phabricator that are protected contain information that is sensitive, or that can be used to cause damage to our systems or disrupt the projects. As such, leadership's direction to us is to keep the number of people who can view those tasks limited to those who must have it.
I completely understand, but to be honest, I'm a little disappointed by the distinctions that are made between WMF/WMDE employees and volunteers. If a WMF/WMDE employee says something like 'I need access because I am responsible for this or that extension and therefore I need to fix security vulnerabilities in it', they (almost) always get access.
I also need to agree with what @Aklapper wrote about this:
Yes, here are a few:
CentralAuth related: T112359, T112320, T201568, T226212, T234371, T237274, T244682. There are quite a few more, but I am too lazy now to start gathering task ids (I would need to ask users with access just in order to get them), since I often don't know them.
T284873 since it is quite related to the work I do at T291994/T274817.
T294713, if it hasn't already been fixed (should be related to T293368).
Also T277919 and T294713, each if not yet closed (both should be somewhat related to issues like T25310/T293368).
Andre is basically asking for more detail than the current "at the discretion of the Wikimedia Security Team" statement on https://www.mediawiki.org/wiki/Security/SOP/Access_to_Phabricator_Security_Issues.
@Zabe I added you as a subscriber to all of the Phabricator tasks you listed above that you weren't already subscribed to. Are there any more you need to see?
For those with access, the procedure for granting access to security-protected content in Phabricator is on Officewiki in "Granting Access to Security Content in Phabricator". That procedure is in accordance with how leadership wants the process to work currently. Also, leadership is the one suggesting carving the most sensitive security- and privacy-related content in Phabricator off to address the problem here.
@Dsharpe: Could you please elaborate who exactly is "leadership" so they could be contacted? Thanks.
@Dsharpe could I get access to T183212 (related to T207580) and T235006 (related to T112359)?
So we have a new, interim director of security at this time: @Jcross. I plan to bring this issue to them soon for reconsideration. And hopefully have an answer before T305731 is fully-resolved.
@Zabe -
Congratulations! I've added you to acl*security_volunteer (see member list), which should now implicitly grant you access to acl*security. Let us know if you need anything else.
@sbassett thanks. Would it be possible to get access to #wikimedia-security on IRC too? As this is one of the two channels used to discuss security issues. My Libera Chat account is Zabe and I'm cloaked as mediawiki/zabe.
There are two ops.
-ChanServ- Entry Nickname/Host Flags -ChanServ- ---------------------------------------------------------------- -ChanServ- 1 legoktm +AFRefiorstv (FOUNDER) [modified 1y 15w 2d ago, on May 20 04:37:17 2021 +0000, by legoktm] -ChanServ- 2 Reedy +AFRefiorstv (FOUNDER) [modified 1y 15w 2d ago, on May 20 04:41:36 2021 +0000, by legoktm] -ChanServ- ---------------------------------------------------------------- -ChanServ- End of #wikimedia-security FLAGS listing
Ok, feel free to ping one of them for access. Security-Team is fine with you being added to that channel. Again, it's fairly low-traffic, compared to _security.