In T369950#10350032, @Jdlrobson wrote:

Thanks @mmartorana for the assessment ! Happy to hear this is low risk.

However, the json-config extension hasn’t been reviewed in some time (T163827, 5 years ago). I recommend conducting an updated review, as it plays a critical role in input validation.

That does seem like a good idea. I've opened T380653.

A strong recommendation is to implement an input sanitization layer before data processing / validation in the chart-renderer service, ensuring that the data is not only in valid JSON format but also protected against injection attacks.

I've opened T380652 for that one.

Also, improving output escaping on the frontend will help ensure all dynamic data is safely managed on that layer too."

Could you elaborate on which part of the frontend would benefit from output escaping so I could capture this correctly in a task?

Security Review Summary - T369950 - 2024-11-22
Last commit reviewed: 3079fd7

@acooper, @Cleo_Lemoisson, @sbassett or @Reedy - Could you please add @Jly to the Security Gdrive?

@Jly - I added you to acl*security_secteam, acl*security and Trusted-Contributors

Hi @Seddon - I’m wrapping up my review and haven’t found any blockers so far.

@acooper - For now, we have selected osv-scanner and Semgrep as the initial tools, as they address the majority of our needs across many languages for SCA and SAST in the first phase or MVP.

@Jly - I added you to acl*security_secteam, acl*security and Trusted-Contributors

@acooper or anyone with the necessary permissions, could you please add Jimmy to @security-team? I’ve already added him to @security.

Hi @CCiufo-WMF and @Jdlrobson - do you plan to address T378305 before deployment?

Hey @sbassett - let’s discuss further in the MR I’ll submit - it should make things clearer.

In T369950#10314778, @CCiufo-WMF wrote:

Hey @mmartorana, checking in on how this is progressing. We deployed Charts to test-commons and testwiki last week, and are preparing to deploy to test2wiki and production Commons as early as next week (for testing purposes only). Pilot wiki deployment would follow soon after but would be awaiting the results from this review.

In T379005#10305616, @sbassett wrote:

In T379005#10296661, @mmartorana wrote:

Regarding the classes, I think for now, since we're aiming for an MVP, we could add a Result class, a User class (to handle different roles), and a Configuration/Settings class to store various tool settings.

I think result could just be a field under the Task model, since it would likely just be a json blob stored on disk or in mariadb. If we're going to leverage django's built-in user management capabilities, I'd argue that we probably don't need a User model at this time, for the API. Eventually we'll likely want to provide basic CRUD and token-granting for user/role management via the API, but that seems beyond the scope of an MVP IMO. I think tool config could likely be handled via a many-to-one relationship in the Tool table.

I also have some suggestions about the model fields. @sbassett, would you like to discuss model fields as well?

Sure.

@Mstyles - any thoughts on this or anything else?

Hey - for the initial authn/z setup, I recommend using Django's built-in system. It's a solid, easy, and secure starting point.

Hey, this looks good as starting point.

In T369950#10285610, @Jdlrobson wrote:

@sbassett @mmartorana following our conversation earlier in the week, we've added the components for client side hydration (with feature flag) so the codebase is now in a stable place and ready for your inspection and advice.

Hi @CCiufo-WMF, @NBaca-WMF and team - following our meeting, I will remove this extension from our risk register since you plan to wait for our review before proceeding with deployment.

Hi everyone, I wanted to share an update to inform @acooper and the security team that this extension will undergo some architectural changes in the coming weeks.

Hi @CCiufo-WMF and team, I understand that your plan is to deploy soon, but after some evaluation, I plan to submit my review by mid-November.

In T369950#10212714, @CCiufo-WMF wrote:

Just a note that we are not yet ready for the Charts service + extension to be reviewed, but hope to be at that point by the end of next week. (cc @Jdlrobson)

After doing some research, I believe we can effectively utilize Django’s built-in capabilities for reporting and managing tabular data in our Universal Security Dashboard. Django’s ORM simplifies data querying and manipulation, while its templating system enables the rendering of tables in web views.

Done (confirmed via T373713)

Hey @jasmine_ - I have granted access to acl*security_sre .

In T371818#10093749, @sbassett wrote:

Just FYI, I'm trying to get a new, dedicated dev/test/stage VPS project created for this work: T373386. Of note: we'll definitely want to create a proper puppet manifest for the primary app instance run under this project (and have it live within the wmf puppet repo), likely very similar to what exists for quarry, but probably simpler in this case.

Security Review Summary - T366233 - 2024-08-21
Last commit reviewed: 18f9619

Hello, thank you for informing us. The review will be published shortly.

Hi @tappof - I have granted access to security@wikimedia.org.

Hi @tappof - I have granted access to acl*security_sre .

Practical Application and Results section added: https://www.mediawiki.org/wiki/Security/Wikimedia_Risk_Calculator

In T370081#9982471, @R4356th wrote:

Seeing as the skin is not actively maintained and the original author has been away for a long time now, would the Security Team be able to merge a patch to this?

Also, this is actually the same issue as T361452; are similar cases being tracked anywhere?

Issue number 2 has now successfully been addressed.

Supplemental announcement is out!

A pull request for this patch has been submitted on github: https://github.com/lingua-libre/BlueLL/pull/18