In T337700#8900003, @Ladsgroup wrote:

I meant it's on windows-1252, we run iconv('windows-1252, 'UTF-8//IGNORE', $text) on it (see moveToExternal::resolveLegacyEncoding)

One of them that's causing error is here:
https://sv.wikipedia.org/w/index.php?title=Diskussion:Bardhyl_Londo&action=edit

It looks interesting:

Parsing it is fataling.

I can ask for a backup to see what exactly was stored for these entries. I'll do that on Monday.

I dont really understand. If the rows were legacy encoded as windows-1252, why would we convert UTF-8//IGNORE to UTF-8.

In T337700#8899829, @Ladsgroup wrote:

When I checked for that page that got deleted in svwiktatiory, they were indeed moved by me. My guess is that they were invalid legacy encoding which would have not caused an error but when moved to utf-8, the check became strict which is fine in some cases but not all. I looked for any mediawiki page in nlwiki to make sure I won't break the wiki: T128154#8899826 I'll go and manually edit those 10 pages to fix their encoding.

I think without the patch the error would still happen just much more silently but still just as broken. I dont think its an improvement to show a blank page

Happy to sign a new nda if neccessary.

In T334940#8885704, @MJL wrote:

In T334940#8848427, @Tgr wrote:

That wouldn't work for graphs using custom protocols like wikiraw: (well, it would work, but you'd end up with a specification you can't really render outside MediaWiki). Not sure what fraction of graphs that would affect.

What portion of Wikipedia/Wikimedia is rendered outside of MediaWiki anyways? Sorry if this is a dumb question, but wouldn't that just be downstream users like site mirrors?

In T335073#8869536, @Galahad wrote:

In the case of zip downloads, how would it be? I didn't download the core with composer and although I applied the patch that Taavi recommended it doesn't work. Should I include the file "composer.local.json" then?

There are also opportunistic limk updates of the page is "dynamic", but yes it is limited.

You can definitely already do this - e.g. make the category used depend on the current time or something. It does seem like this might make the problem worse though.

So I was chatting with @Yug at the hackathon about this. He was hoping this could be reconsidered.

I dont think it falls afoul of that as long as it is reflecting DB state (current contents of categorylinks) and not currently parsed page.

In T336632#8861465, @Tgr wrote:

I think a lot of confusion around Graph comes from the fact that it tries to serve two very different use cases:

• Visualizations based on structured sequential data (as opposed to Wikidata which is structured key-value data). You put the numbers in a data table on Commons, Graph pulls in the data and renders a chart or map. This allows for data sharing across wikis, machine-readability and writeability, separation of article maintenance and data updates etc. etc. It would basically bring the advantages of Wikidata to another domain of data.
• Rich interactive content - maps or diagrams where you can zoom in, animations explaining how machines work, whatever.

As far as I can tell, neither of these had any appreciable uptake. Most graphs don't use external data and just dump it into the wikitext; most graphs don't include a meaningful level of interactivity, and are very basic data visualizations like bar charts or pie charts. The future of the extension is in doubt because of technical issues (although of course the lack of adoption influences how much effort is spent attempting to fix those technical issues), but its failure at adoption is because of product issues. Using it is just not intuitive enough and not well explained; using it in a non-trivial way (such as actually providing rich media), even more so.

So I think the key question is not what's technically possible (or cool from a hacker's point of view) but what would editors be actually willing to use?

In T336595#8853148, @Bouzinac wrote:

Aside the vega and security problems, would there another possibility to call and show directly the result of a wikidata sparql query, for instance, https://w.wiki/6i7n inside a wikiarticle?

Extdist is also using replica currently.

The main reason i would argue for iframe sandboxing is that it ties it to the browser same origin policy.

I've been experimenting a little bit in this direction with https://www.mediawiki.org/wiki/Extension:Monstranto

It would be the same parser output since it would come from the parser cache

That seems much simpler. You'd loose interactivity of graphs, but let's be honest... the interactivity-part has been an 8 year long nightmare. Maybe its time to put that to bed and accept defeat. I'm sure it would piss off many people, but the entire organization is over committed, choices unfortunately have to be made.

Are they? Something like {{Map with marks}} seems entirely compatible with a specification JSON template approach to me. (Migrating existing graph templates would certainly be unpleasant work, though.)

The specification would be less flexible - right now you can use templates or Lua to make the specification dynamically depend on the parameters of the graph, this would become impossible. Other than the data and maybe a few other predefined modification points, specifications would be static. Not sure if this would significantly impact real-world usage.

This seems like it would be easy to add as an extension (as long as it is just config and not loading other extensions). I'm not sure that i think it makes sense in core, or at least not until it has a proven track record of people using it.

In T335073#8800043, @Tgr wrote:

Pinning indirect dependencies doesn't make a lot of sense for an application which has a plugin system, as the plugins have their own dependencies and pinning might cause unnecessary conflicts Pinning is generally something better performed by the site administrator IMO (e.g. Wikimedia wikis pin versions via mediawiki-vendor).

I think a simpler solution to the problem of Composer installing compatible extensions is for extensions to increment their major version number when they drop support for a version of core.

However, this seems like what FallbackSlotRoleHandler is supposed to do.

In T335770#8825240, @Brycehughes wrote:

@akosiaris if I curl it from San Francisco (VPN) I don't see it. If I curl it from Belgium (no VPN) I see it. It's being seen by at least one other experienced editor at Wikivoyage as well. If it's not CDN... what could possibly be up with the geographical discrepancy? s-maxage=1209600, max-age=0??

Sorry, i just realized i misunderstood how this feature worked, and I don't think it is a viable solution to the problem it is trying to solve. I still stand by my comment about code-owners being a path that we as a community should move forward on. However i no longer object to this feature being removed, as i don't think it is a viable way forward to the versioning problem, since using it means you cannot install the extension independently of composer, which is kind of critical to how the majority of people use composer. So consider my objection withdrawn.

I don't know how technically feasible it is but I think it should be possible but out of core, into a dedicated repo that could have core as a submodule.

So, I sort of had a change of heart about this task. (To be clear because it is confusing, by this task, i mean removing support for depending on the fake mediawiki/mediawiki dependency in composer)

Other users (@SHB2000, @Bawolff) reported seeing "Anorexia is fun" two days ago when I reported it, although SHB2000 now reports that it's clean. (The vandalism occurred on 28 April; I reported on 2 May)

Historically i think the concern was you load a normal page as a csv file, parse out the edit token from the html source, then leak the edit channel via a side channel to an attacker. [Otoh good luck executing csrf style attacks on a modern browser, so maybe that specific scenario is less relavent now, although similar scenarios may still matter]

I mean, for any dynamic parser function, you'd be kind of hoping that you retrieve the same parser output. {{NUMBEROFARTICLES}} is commonly used as a very bad pseudo-random number generator on enwiki. It seems like you would often retrieve different parser outputs and the graphs wouldn't match if they used dynamic parser functions, unless i misunderstand the plan.

In T332850#8815111, @Billinghurst wrote:

In T332850#8812580, @Mstyles wrote:

The security team would like to temporarily undeploy this extension due to security concerns. The target date is the week of May 1 for the undeploy.

Do we even have any stats on its use?

Actually, i just read:

What does "temporarily" mean here? It seems unlikely anyone is going to come around and fix the extension any time soon. If its going to be permanent we shouldn't mislead people.

I mean, traditional in the sense of loading it via an URL. It would still be sandboxed. That would make it behave as if it were from a different domain on almost all browsers where we actually load Javascript

traditional iframes (results in a bunch of extra requests + need to pass state, which imposes GET length constraints)?

The fact that there has been close to no issues in 20 years, where Graph has had many issues even before the current one.

Im not sure we should. This sounds like useful information to people auditing extensions or developing extensions, but im not sure it is useful to average end user.

I think recent events further suggest that migrating to graph would probably not be a good maintainability move.

It is likely you had a system update, and the font was added to your system. It is likely that this will depend on what operating system you are using. That or you installed the font locally.

After all this done, are you going to publish the full explanation about the security breach

T182536 has been around for more than five years

In addition to fixing the underlying issue, i think this bug shows that vega really should be rendered into an iframed sandbox.

With all due respect to everyone involved, i really think its not ok to disable something not actively being exploited [i assume, i dont know), and is used in main namespace for real articles, without giving at the bare minimum a day notice (wikitech-l + mass message VP) so users can fix articles. Even if this was actively being exploited (or is likely to be upon announcement, has public PoC, whatever) i would expect comms to fast follow disabling. At least inside of an hour.

In addition to this being essentially duplicated info (that is often wrong as in many extensions its only used in debug mode so typos go unnoticed), i feel like this really doesn't make sense to specify in extension.json.

Has anyone told the affected projects that this will happen?

I kind of wish there was basically some sort of hook here where i could combine things in arbitrary ways. I don't think a few predefined options is ever going to be sufficient.

Note that all browsers on iOS use WebKit engine (Chrome, Opera and even Firefox). So I doubt Puffin Browser can do anything about what they support. This is due to Apple policy which bans browser engines on their store. I guess most devs know that, but every browser on iOS is a skin over Safari (mostly).

In T332971#8779227, @Bawolff wrote:

As quite a few Wikimedians experience issues with IP blocks and related it might be useful to have a shared hybrid session about this problem and work on possible paths to advance it.

I'm not sure what this has to do with DNS

As quite a few Wikimedians experience issues with IP blocks and related it might be useful to have a shared hybrid session about this problem and work on possible paths to advance it.

Why didn't we just add .map to the whitelist?

do you need all of these permissions still?

Some information is public. Private data will not be released.

Commons already runs tests on files via bots to detect embedded info, it wouldn't surprise me if they might already detect this - although previous work was more about detecting multi-gb movies embedded in jpg files so maybe not.

The webpack vulnerability is pretty silly. It is basically - if an attacker can modify your source code, then they can run arbitrary code.

In T249573#8759975, @Ladsgroup wrote:

I ran into this when cleaning up includes/ (T321882). You can bring back composer supported functionality via a new repo that uses core as submodule or anything like that. So I'm planning to merge this patch soon.

Just noting because there were some user complaints on project:Support_desk, and it doesn't seem to be mentioned here explicitly - Firefox 52 is the last supported version on windows vista, which is no longer supported.

[Making public since resolved]

[marking as public since resolved]

@Mstyles Can this be added to next extension security supplement?

In T333980#8755485, @Lucas_Werkmeister_WMDE wrote:

			return '<strong class="error">' .
				wfMessage( 'googleanalyticsmetrics-invalid-url' )->text() .
				'</strong>';

Doesn’t this need to be ->parse() or ->escaped() to prevent HTML injection from the googleanalyticsmetrics-invalid-url message?

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GoogleAnalyticsMetrics/+/905661

In T333770#8749150, @EpicPupper wrote:

Cloudfare's business interests do depend on violating privacy; the US DHS has commented that the data it has (vis a vis their MITM proxy, for example) is "valuable" and offered to purchase it (source).

I guess b16734996ad55b9463 broke this.

This seems to have regressed, but given how old this bug is, i just created a new one - T333776 instead of reopening this one