In T284943#7156513, @bd808 wrote:

@sguebo_WMF Is this a modification of the approval given in T150679: Some Labs DB user_properties view fields are sensitive to expose that preference?

For context, the privacy engineering audit regarding the wiki-replicas is part of a body of work that is being done internally by the Security team. But I concur that a parent public ticket would have made sense too. I’ll keep that in mind moving forward.

I had the chance to sync directly with @Varnent who's in charge of those platforms, and I surfaced the solutions proposed above. So far, applying the CSP change at the Nginx server level on WordPress VIP does not seem to be an option. Instead, disabling Twemoji.js through a WordPress plugin would be the applicable solution. The Security-Team is supportive of this approach, which was suggested earlier in this thread and has already been used on the techblog (Cf: 4447d8f).

In T275754#7031267, @Waihorace wrote:

Thanks for the ping. I have added a sentence to reflect the concern on the gadget description for zhwikinews where I am a sysop.

Indeed, @Xiplus , do you find it feasible if we move your script to the wiki so that the concern could be eliminated?

The Foundation’s Privacy Policy mentions the commitment of “never selling [user] information or sharing it with third parties for marketing purposes” and “[...]only sharing [user ]information in limited circumstances, such as to improve the Wikimedia Sites, to comply with the law, or to protect you and others.” In principle, gadgets that share user information with third parties do so in violation of this policy. However, it is worth noting that some of these scripts are used by thousands of contributors. Therefore, I think there should be a short-term and a long-term approach to tackling this issue.

I would be grateful if you clarify what you are requesting/ expecting. Are you suggesting that those gadgets be taken down or that their authors be required to draft an on-wiki heads-up, for instance on the widget's talk page? Or is it totally something else you're asking for?

In T259421#6374107, @sbassett wrote:

In T259421#6373857, @Krinkle wrote:

Since the WordPress blogs have none of the MW legacy, I suppose it'd make sense to set the CSP rules at the server-level for the blogs, not from within PHP.

I'm not sure if we have access to nginx config settings at Auttomatic, but that would be the best approach, sure. I was more implying that we could copy the current Wikimedia prod CSP as a starting point and tighten it as appropriate for the various WP sites referenced within this task.

Originally I was interested in having the risk rating field being added to New Task. However, while looking at the tickets your referenced, I could see that the Security Type Advanced form (73) already has the Security rating field, although it seems to be locked at the moment.

I completed a prototype with basic filtering options. For now, one can filter by project (tag), year when the ticket was created, and severity. The code base is available at https://github.com/samuelguebo/vm-dashboard. It's public for now since there are no credentials or sensitive data there but I'm glad to make it private if there are any objections.

Thanks @Reedy, I intend to use the Phabricator's Python library since it's pretty straightforward.
I guess I can grab the token with you once you've gotten the chance to create it.

In T279140#6968192, @sbassett wrote:

In T279140#6968184, @sguebo_WMF wrote:

I see, then it's fine since I was able to collect all the existing tags from the Conduit API as well using the Vuln- prefix.

Sounds good. Not sure if you're using personal API tokens for this, tied to your Phab account, but we probably shouldn't do that. We do have a bot though we'd likely need to recover credentials for that and add you and maybe @Reedy and myself as maintainers.

For now, I think we can make this public. If it becomes necessary to include sensitive data here, directly within the task, we can always protect it again.

Hey @sbassett,
Thanks for chiming in.

Some initial tests with Conduit enpoints
Pulling the Phabricator ID (PHID) of all tags starting with the Vuln- keyword:

curl https://phabricator.wikimedia.org/api/project.search \
    -d api.token=api-token \
    -d constraints[name]=Vuln-

In T276852#6893824, @Dsharpe wrote:

I added you the acl*security_team group already.

@sbassett , coolio. I guess once @Reedy has added me to the acl*security_team group, I can close this one.

Hey @sbassett, thanks for creating this and having checked a bunch of boxes already.

• I think I still need to ping a Phab admin to add me to acl*security_team.
• I wasn't sure about the Deployment & stats private data part, since per https://github.com/wikimedia/puppet/blob/5dca2a73bba83ad469a20cc38e0d0c15761befa3/modules/admin/data/data.yaml it seems I am already within the analytics_privatedata_users and deployment groups — restricted being a subset of deployment.
• I'll figure out how to enable the word highlighting for my IRC client (Limechat)

In T264797#6630512, @Kormat wrote:

Hi. I have merged the gerrit change, but

• i'm not sure how long it's going to take to take effect
• the current redirect is a 301 (a 'permenant' redirect), so browsers that have visited the url before are likely to still go to the old location.

Hello @Dzahn, can the 2030.wikimedia.org subdomain redirect to the new url: https://meta.wikimedia.org/wiki/Wikimedia_2030 ?

Handled through ca@

Thanks again for the patch. While he can access the stats server (stat1005.eqiad.wmnet), Nahid is not able to access the maintenance server.

2FA is now removed from the account User:Nabin K. Sapkota

In T254035#6209002, @elukey wrote:

elukey@krb1001:~$ sudo manage_principals.py delete sguebo
elukey@krb1001:~$ sudo manage_principals.py create sguebo --email_address=sguebo@wikimedia.org
Principal successfully created. Make sure to update data.yaml in Puppet.
Successfully sent email to sguebo@wikimedia.org

Done! Sorry for the lag!

No worries, @elukey. Many thanks for your assistance!

Hey @Pchelolo, do we know whether the patch might be merged soon? Thanks for the work there.

Hello Cyberpower678,

Hey @Aklapper and @19.abbas.75, the email was received through ca@ and we've proceeded with disabling 2FA for User:Abbas dhothar on pnbwiki.

@Aklapper: Yes, I realized it shortly after my previous comment. I handled it myself. Sorry for the confusion :)

Thanks very much for your invaluable support, @Quiddity!

Hi @ArielGlenn, the access works just fine. Thanks!

Hi @RobH, I hereby confirm that I am the one who generated the key below:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDcAX6WTg1eISyLlAAfCB6JefHgZQFJRptkuj1ivLPHtOCvOFilAJFZRNlBwb5Mzrfucs6dMMPLg+UJLdJz2YM/g06Iwl1xYYW1pcLIl7mrrq5x54mQCFmacxLQLk1tqG5YvChJF8SbcH+Z1LvHhEy+ElBlQRnhBhi9YuTzLyy12aHVewnnGr+I+XPxG1Hg7gKZgbcsxT8L7XXcg0EGMNxhciPKUK0nK3PEmKWR0Xlx4hLnQ2hDYLqRmGAM7zj7uJ1tq1qKHW5DZvmlojdfdWFmFbVQDvP0HJHruwvudSs2re+5iwsztP3La4iXAj7c3fPIrYNgXjxMRKc4GgXHPZsCd3q6bVkTNRp0mcb3PWPaTIs/QdR9T6Z6M6fuUlEFRTjP9SqGHwCR5P//sS/aJSpf9HUjE8l88vVF0HW8m7ZVE1/xVERzw1fOhE+BAnO6qEjxnyqLnykdBIEVPsNy2MTIo98dxgzykmP5aMwcYnKPiUJ4nsDsaLoPct9iftJF8nNcbk+j5BHHNfiSM6V220rWox2IYM9M/OChaPuoRVIHQMTQ17ZaE7+JO93xosFigB0IpuMk4vwV+Z/vhk3NDoAjcw1gFSKnz8pKGrBI8CV2ls/32w8jcNAJgNdP1cjqLwksAbKvyk1TDZi6sXYW2L2Rr6YZ8Rb6g2SeBe/LPs44sw==