Personally, i don't think this mitigation is worth it given the low risk. After all, most API requests aren't even authenticated.

See https://www.php.net/manual/en/language.types.string.php#language.types.string.parsing

I'm actually not sure what the issue you are reporting here is. All of this is expected behaviour.

"****\$" is the correct way to write ###$ in php

See https://en.wikipedia.org/wiki/Template:CineMol for a pure lua solution.

To be clear, the static parts of vega only. Vega had a lot of dynamic interactive features (which nobody ever used) which isn't viable with this method. Additionally some data sources are not available from lua (e.g. i think vega let you make sparql queries)

In T401987#11365587, @daniel wrote:

According to turnilo we are getting a couple of hundred requests per day with the xslt= parameter set. All for action=parse, from various IPs with UA strings that look like browsers. That suggests a Gadget.

EDIT: it uses https://en.wiktionary.org/wiki/MediaWiki:ExtractFirst.xsl which exists on several .wikis

While I appreciate this probably wasn't done lightly, i do find it sad as before people become contributors they have to be lurkers, and cutting off lurker access may reduce our stream of eventual contributors.

I'd propose that we abandon following specific specs, and instead use baseline of -3 years ago (So right now that would be baseline 2022). This would roughly correspond with what mediawiki's browser compatibility is for grade A browsers - https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix

This kind of comes down to what is the threat model of css-sanitizer and what does it want to prevent. I feel like a lot of css-sanitizer development is paralyzed by not knowing what the goal is.

This might be a little in the weeds for tech news, but i think this is an interesting change for wikipedians who write templates with TemplateStyles as it opens up some new possibilities such as a limited form of having template parameters affect templatestyles.

For a non-graph example, I made a template that can render molecules using this feature - https://en.wikipedia.org/wiki/Module:CineMol . Its a very open-ended feature, so your imagination is really the limit.

Looks like this is about: https://exiftool.org/TagNames/Sony.html

I don't understand why T405861 (Lua implementation) was merged and not this task. The effects for readers are the same, but T405861 only works in Lua (so less use cases for creators). I don't understand this decision.

In this solution, SVG is treated like a monolith. Perhaps, it structure could be represented by nested Lua tables corresponging to nested SVG elements?

In T405861#11307439, @Quiddity wrote:

I think this feature sounds exciting, per your comments and linked-experiments above, and I worry the current draft-entry, and the documentation it links to, doesn't communicate that clearly to newcomers to this feature. In particular, the documentation doesn't seem to contain any specific examples of how this can be used. We don't usually link to user-sandboxes, especially English-language-only ones, so that's not a great option.
How could we improve the announcement, and the linked documentation, so that the powerful possibilities are more obvious to readers?

Scribunto modules can now be used to generate SVG images. This can be used to build charts, graphics and other visualizations dynamically through Lua, reducing the need to compose them externally and upload them as files.

The stuff in my subpage is kind of cool demos but probably not the features envisioned usecase.

I think i might have missed a factor here.

Am i correct in assume the CSP header in question is: default-src 'none'; frame-ancestors 'none' ? That's restrictive enough to break pretty-printing and help pages.

I agree with Danny that I think this should be declined. There are legit reasons to watch non-existent pages.

I was under the impression that user_touched was not updated on login. Maybe I'm mistaken but a quick look through the code I don't see anything that would set it on login.

In T407709#11288068, @SD0001 wrote:

I created a POC for this. I'm not sure how useful it is though. I was mainly aiming to have the normal transclusion syntax for such pages return the image instead of the code. But it turns out Content's getWikitextForTransclusion() is expected to return wikitext without strip markers, so it doesn't work unless/until <svg> is recognized markup (T334372).

Also, even if it worked, for SVG code to accept parameters (eg. {{{widith|20}}}), the parser will have to be run on the code, which could result in surprises in cases where SVG code looks like wiki code. (Unless there's a way to tell the parser to expand just parameters and ignore other wiki markup?)

Another interesting idea would be if there could be some :addVariables() lua call, which would inject into the svg a style tag containing all the skin's css color variables (e.g. --color-base et al). Probably kind of hard at the moment due to the way skins are structured.

In T407159#11288246, @MusikAnimal wrote:

In T407159#11269636, @Multichill wrote:

Able to login as the bot and https://commons.wikimedia.org/wiki/Special:BotPasswords/ErfgoedBot-Toolforge is configured

Could you provide the link from Special:OAuthListConsumers? I.e. something like Special:OAuthListConsumers/view/[hash]. When searching there I was unable to find any OAuth applications with the name ErfgoedBot-Toolforge or variants of it, nor did I find any that were published by Multichill.

Perhaps this should be public to give it more eyes. Afaict this is about account security but not a "security" bug (ie not a security vuln) and there is no private data here.

I created a POC for this. I'm not sure how useful it is though. I was mainly aiming to have the normal transclusion syntax for such pages return the image instead of the code. But it turns out Content's getWikitextForTransclusion() is expected to return wikitext without strip markers, so it doesn't work unless/until <svg> is recognized markup (T334372).

Maybe it should be an "XML" content model (or perhaps an SVG model extended an XML content model). for example, i see people put random kml files as a wikipage sometimes, which would make sense to be marked as XML.

In T407710#11288105, @Izno wrote:

Does this not run into the same security issue as described in T5593: [Epic] SVG client side rendering regarding scripts potentially uploaded before the dawn of sanitization?

[Forgive me if this is off topic] Some experiments taking images from the Animated_SVGs category on commons: https://en.wikipedia.org/wiki/Module:Sandbox/Bawolff/interactiveSvg

One potential problem though is that when purging an image page, doing the purge POSTSEND might make the user see stale data as typically users don't have a cache busting cookie for the image server. So i guess file purges should still be PRESEND.

Part of the issue here is that curl removed support for http/1.1 pipelining which made this much slower. Edit: Seems like without pipelining it just opens multiple tcp connections at the same time, so the latency difference really shouldn't be that much

I think the next obvious question is can we make mw.title.new("Media:foo.svg"):getContent() return the text of the svg if the file is below a certain size. Then we could have lua do post processing on svg files, to e.g. change the colour of something.

I just encountered another wiki where doing these PRESEND was the cause of a major save time latency (was taking multiple seconds to send cdn purges). I think this is a major performance hurdle for most wikis using HTTP based cache purging.

I tried doing ?action=purge of the image page, which didn't change anything (Other then reset the age header), so I suspect its missing from eqiad swift but is present in codfw swift.

I made backports of this patch to 1.44 and 1.43. The backports are non trivial enough I'm not sure if other people want to review them, instead of the usual self-review +2 for backports.

In T85085#11274414, @sbassett wrote:

In T85085#11273487, @Bawolff wrote:

Should i mention this to commons users to be on the look out for issues (keeping details vauge) or do we want to keep this on the down-low?

I think it's fine to generally discuss it once it rolls out to 1.45.0-wmf.23.

Also if this is a threat we are worried about, seems like we should also be worried about:

Should i mention this to commons users to be on the look out for issues (keeping details vauge) or do we want to keep this on the down-low?

In T364685#11267374, @cscott wrote:

The reason is that border: var(--foo) var(--bar) is invalid, while border-color: var(--foo) var(--bar) is valid. See T361934#9692764.

At the very least, it doesn't make sense to allow border: var(--foo) but not allow border-color

We do display format information for other files in getLongDesc(), so it wouldn't exactly be out of place.

@cscott seems to have some objections to this at T361934

This seems fine to me, but there seems to be some comments in the source code about not allowing variables in properties that support multiple comma separated colour values (E.g. border-color). I don't really understand the threat that is supposed to be about, but light-dark would fall in the same bucket.

Well i guess i'll make a patch and see what people say

In T320322#11244265, @stjn wrote:

I think the second security requirement is not really necessary if the variable name would enforce what values it might have and TemplateStyles would only accept CSS variables of a particular type. As you yourself say, it’s not a particularly strong protection anyway, so unless it would be required by TS to validate the variable values, it doesn’t seem useful to have.

Copying what i wrote on T200632#11221909 as its really for this ticket

This is a bit confusing. It might be more clear with a more minimal test case - where the example test cases are as small as possible with the least about of subtemplates as possible while still demonstrating the issue.

Perhaps this isn't the best place for this conversation...

In T394396#11238391, @SomeRandomDeveloper wrote:

As I mentioned on gerrit already, as far as I can see, $this->buttonLabel seems to either be parsed (L63), escaped (L69) or intentionally raw HTML (L72). It shouldn't be escaped in buildCodexComponent. Instead, it should be marked as exec_html and escaped by the caller, which https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1193175 (the fix for T402313) does already.

@sbassett What are next steps here?

In T85085#11229455, @TheDJ wrote:

@Bawolff impact seems acceptable to me. no concerns from my end.

Data: urls are also banned except in @font-face. The rationale behind this is unclear.

TIL... I'm guessing it is to make use of fonts and preserve rendering, which isn't otherwise possible with text, but as we do not allow non-free fonts, the usage seems pretty limited. It's also not documented anywhere else as far as I could find.

In T405301#11223001, @Alex44019 wrote:

Session yes, if they're logged in, or reached Special:CreateAccount/Special:UserLogin. Anons get the ChronologyProtector cookie but that only lasts 10s, and might also often not be configured to exempt from caches on third-party setups.

The only exception could be Lua functions changing some attributes of the pages where they are called; like parser function can.

I suspect what happened here is that XMP-Reader doesn't enforce array types when the value is specified as an attribute

I assume this is about setting the variables not using them, as you can already use var() for colour values in templatestyles.

In T405138#11217566, @matmarex wrote:

@Bawolff Shall I make a release of XMPReader, or do you have some other patches in progress?

Wouldn't the editor having a session prevent them from seeing stale pages?

In T334372#11214258, @Bugreporter wrote:

In T334372#10368857, @Bawolff wrote:

As an aside, I just realized you can do a surprising amount of drawing with just CSS. See https://en.wikipedia.org/wiki/Module:Sandbox/Bawolff/canvas for an example.

Please note using div+css to create charts (e.g. https://en.wikipedia.org/wiki/Template:Pie_chart) may be considered a hack instead of a proper solution - the "chart" is not a proper image you can download.

In T334940#11214179, @MBH wrote:

Why not allow to use external data? External data could easy be safe, for example if it's in JSON (and mediawiki API returns pageviews data in json and XML, also MW API couldn't return destructive data at all).

I'd just like to remind everyone that WP:IDONTLIKEIT complaints are unlikely to change hearts and minds. Individual tasks for individual missing features along with justification as to why that particular feature would be useful will be more likely to yield results.

In case its not clear, sending this PRESEND can cause significant latency if you are using traditional HTTP purging and have multiple cache servers. I think the request here is to change this to POSTSEND unless there is a compelling reason why doing that would be a bad idea.

P.s. the goal of this task is to get a yes/no answer on if this is an acceptable idea. Once that is decided, i'm happy to do the implementation if the answer is yes.

I'd like to propose a compromise approach: supporting css variables only inside calc(). I think this would address Tim's concernd since calc() can only work with numeric & dimensional values.

"This page documents the latest version of the Scribunto extension. Some features may not be deployed yet."

In T376564#11209044, @IKhitron wrote:

So, maybe this should me mentioned somehow in the manual.

I'm opposed to adding parser functions for something this niche, especially without a concrete usecase.

For cross reference: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/140975

[I moved this back to "to-triage" on the user-notice work board, since this finally got merged I wanted to bring attention back to it. Hopefully that was the right thing to do].

Is it intentional that this is a non-expensive parser function?

I was a bit unsure on what the best i18n message for digitalSourceType is. I went with "Source of digital media", but potentially that could be misinterpreted as who provided the media or where it came from, where this field is the mechanism that was used for creating the digital file. https://www.iptc.org/std/photometadata/documentation/userguide/#_guidance_for_using_digital_source_type is the official docs on the field.

So if we wanted to extend XMPReader to also read commonly used subset of RDF in SVG files that are not xmp compliant, i think what we would have to do:

• treat <cc:work> as <rdf:Description>
• if we see <cc:Agent><dc:title>Some name</dc:title></cc:Agent>, we ignore the xml tags and just take the inner content. especially in dc:creator
• [Less important]: Make http://purl.org/dc/elements/1.1 be an alias for http://purl.org/dc/elements/1.1/ (Perhaps do this in SVGMetadataExtractor instead of XMPReader
• Be less strict on types. e.g. In xmp dc:Description is a language field, but in many generic svg files it is a simple value. You'd probably have to make it accept simple values for anything that is an array type.

It also seems to have a problem in certain cases it will merge the text node of a qualified statement with the next node.

[removing XMPReader tag, as this is an issue with metadata display in MediaWiki not extraction]

I think doing this for ->parse() would be fine, but I'd be nervous about doing this for ->escaped(). If you are using the output of ->escaped() in an attribute, but instead it outputs <a href=.. that could lead to an xss.