Thanks!

In T379677#10332098, @matmarex wrote:

Resolved now, right? Or are you waiting for the MW release to close this?

Resolved now, right? Or are you waiting for the MW release to close this?

Change #1090551 merged by jenkins-bot:

[mediawiki/extensions/WikibaseMediaInfo@master] Avoid unnecessary use of RawHtmlMessages

https://gerrit.wikimedia.org/r/1090551

Pushed as https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1090816

In T379677#10314397, @Tgr wrote:

T379677.patch1 KBDownload

Change #1090551 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/WikibaseMediaInfo@master] Avoid unnecessary use of RawHtmlMessages

https://gerrit.wikimedia.org/r/1090551

Change #1085432 merged by jenkins-bot:

[mediawiki/extensions/StopForumSpam@master] Remove stopforumspam-is-blocked message from RawHtmlMessages array

https://gerrit.wikimedia.org/r/1085432

Change #1085432 had a related patch set uploaded (by SBassett; author: SBassett):

[mediawiki/extensions/StopForumSpam@master] Remove stopforumspam-is-blocked message from RawHtmlMessages array

https://gerrit.wikimedia.org/r/1085432

In T377222#10279264, @Tgr wrote:

In T377222#10279189, @sbassett wrote:

It still has <strong> tags and is parsed due to the wikitext links. I guess one could argue that the <strong> tags are superfluous.

But it's parsed so it's safe HTML, not raw HTML.

In T377222#10279189, @sbassett wrote:

It still has <strong> tags and is parsed due to the wikitext links. I guess one could argue that the <strong> tags are superfluous.

In T377222#10278803, @Tgr wrote:

• stopforumspam-is-blocked (20bb7d1d - seems wrong? the message is not actually HTML)

The copyright footer is not shown on Special:UserLogin, nor (as far as I can tell) on any other page that has JS disabled;

Raw HTML messages not listed in T377222#10241289 but found by codesearch:

• stopforumspam-is-blocked (20bb7d1d - seems wrong? the message is not actually HTML)
• donate_interface-otherways (it's a Wikimedia-specific extension, only used on a very locked down wiki, so probably fine? still, seems easy to replace)
• wikibasemediainfo-time-timestamp-formatted (96e5a07e - no good reason for it to use raw HTML)

HTML in copyright messages is a legacy feature at this point. I don't think it makes sense to expend any effort on sanitizing it when security-conscious installations can just disable it.
(We should probably make it default to disabled in the next release, though.)

A related thought I had today: do we disable raw HTML messages on Special:UserLogin and related pages? Because not loading user or site scripts on those special pages is a security feature, I believe (we don’t want to let interface admins steal user’s passwords).

In theory since T45646: "MediaWiki:Copyright" message allows raw HTML we haven't been using most of these messages in Wikimedia production. $wgAllowRawHtmlCopyrightMessages (already false) should disable all the copyright-related ones (in favor of wikimedia-copyright-footer etc) except the MobileFrontend one which is not raw HTML anymore (fe15e9c776). googlesearch is unreachable. gadgets-definition is irrelevant. That leaves the various non-copyright mobile-frontend-* messages. Probably we can just fix those?

Hall of fame update deployed: codfw, eqiad.

Change #1082089 merged by Mmartorana:

[operations/deployment-charts@master] Update miscweb: security-landing-page to latest image tag

https://gerrit.wikimedia.org/r/1082089

Sure, fine by me.

Change #1082089 had a related patch set uploaded (by SBassett; author: SBassett):

[operations/deployment-charts@master] Update miscweb: security-landing-page to latest image tag

https://gerrit.wikimedia.org/r/1082089

In T377222#10248420, @Bawolff wrote:

Also this seems more like a feature request than a security issue. Maybe this should be made public so a broader group can comment on it.

Also this seems more like a feature request than a security issue. Maybe this should be made public so a broader group can comment on it.

I feel like safemode would be difficult to use as a security feature. Its not sticky, users would have to manually type in the url of every page. edit: appearently this is a user preference now, which maybe changes things with regards to how much it makes sense as a security feature.

In T377222#10243566, @sbassett wrote:

@Lucas_Werkmeister_WMDE - Is this more about the convenience of having a query param to disable certain messages or is it more about trying to expand the security posture of safemode as @Krinkle alluded to? The former would likely have a simple solution, but I'd probably agree that, if it were to be implemented, it should never be enabled in Wikimedia production.

mmartorana merged https://gitlab.wikimedia.org/repos/sre/miscweb/security-landing-page/-/merge_requests/6

I can't reproduce any of the problems today.

@Lucas_Werkmeister_WMDE - Is this more about the convenience of having a query param to disable certain messages or is it more about trying to expand the security posture of safemode as @Krinkle alluded to? The former would likely have a simple solution, but I'd probably agree that, if it were to be implemented, it should never be enabled in Wikimedia production.

sbassett opened https://gitlab.wikimedia.org/repos/sre/miscweb/security-landing-page/-/merge_requests/6

In T377168#10242168, @Mic1337bie wrote:

Can I ask about your CVE processes (CVE assign process)?

Hi, I can confirm that it is already fixed (can not reproduce from POCs). I am impressed, so quick action. Professional and responsible approach.

IMHO this would be pointless if restricted to $wgAllowRawHtmlCopyrightMessages, as there are other raw messages. $wgRawHtmlMessages is still a small set of messages, but only about half of them are copyright-related.

@Bugreporter2: Please bring this up in T318435 (and I don't see some "committee" ever mentioned) - thanks.

Thanks to all who have worked on fixing this.

Change #1080836 had a related patch set uploaded (by Brian Wolff; author: Brian Wolff):

[labs/codesearch@master] Use a CSP policy to reduce risk of XSS

https://gerrit.wikimedia.org/r/1080836

Change #1080829 merged by jenkins-bot:

[labs/codesearch@master] SECURITY: Escape slashes in json to prevent XSS.

https://gerrit.wikimedia.org/r/1080829