Thanks @EBernhardson for the productive and interesting meeting yesterday.

Thank you very much, I sent a calendar invite.

I have a plan for fixing this. This is just some notes for myself

• Add myself to the Privacy Engineering phabricator project so that I (hopefully) get emails for any new task
• Setup a gmail rule to forward these emails to Asana
• Document the above process so it could be run by any team member in future by adding themself to the project and configuring the same gmail rule

I'm going to pick this up initially to help prioritize. @EBernhardson would it make sense for us to have an initial meeting to get a sense of the risk involved? Anyone else to invite on your side. I'll invite some folks from product security

@mmartorana could this be actioned since the approval was given?

Regarding this ticket, I would recommend syncing with @MoritzMuehlenhoff as I believe he had ideas and thoughts for scanning and updated running containers. This is different to CI of course, but would be good to be aware and plan the overall approach together.

I like these headings, thank you.

I did create some hacky code that may help, it queries the API for each wiki to determine deployment status of skins/extensions. https://gitlab.wikimedia.org/acooper/extusage. There is a dump from the historical data in october here: https://docs.google.com/spreadsheets/d/1SBU6sPHSrkWmxLbMaUu1WoEVEPVQTmSHUgo_DVT7c4c/edit?usp=sharing

Namely or just the gmail synced address book.

You could also require messages of acknowledgement to be sent across at least two authentication domains to increase the security. So say a slack message (linked in a phab comment) and a phab comment.

Oh and all that is required is for the verifier to also post a message authenticated to their accounted confirming they have verified the identity. The verifier in this case is someone from the persons team or management chain. So its not a fixed identity.

I was assuming finding the person would be easy - it would be maybe their manager? Which is easily available from the address book.

We have concerns that the following code snippet from this feature contains a XSS that might be triggered by a malicious link opened by a user:

On review of the available penetration testing evidence from the vendor it was confirmed appropriate independent testing had taken place and we have now downgraded the risk to medium.

I had another thought about this requirement. Besides the higher level organizational header names, it would be helpful if the risk of those columns could be collectively expressed by a single value.

I'm currently in some discussions with Greg about how to handle the potential risk in this component. Will update the ticket when we have reached a decision on what to do next. For now we will pause the security review until this is decided.

It appears this issue has been (perhaps unintentionally) publically disclosed at https://fluidattacks.com/advisories/blondie/. @sbassett has asked legal to assistance with how to respond regarding the disclosure.

There is also a separate issue which is a configuration based Remote Code Execution vulnerability in the superset.wmcloud.org instance (not the superset.wikimedia.org instance), caused by the use of a guessable secret key in the Flask superset configuration as described in this article: https://www.horizon3.ai/cve-2023-27524-insecure-default-configuration-in-apache-superset-leads-to-remote-code-execution/

I followed these instructions already which requested rsa type (maybe worth updating the instructions if ed25519 is preferred now?)
https://wikitech.wikimedia.org/wiki/Yubikey-SSH

Thanks I added the SSH key.