In T334940#8801549, @Sjoerddebruin wrote:

I see various reports on the Dutch Wikipedia about the pageview graphs missing on the action=info page. The error message doesn't show up there as the link is simply ommited, can something be done about that?

It will be fixed when graphs get reenabled.

I think the question was whether something can be done about that until graphs get re-enabled.

In T334940#8801455, @The_RedBurn wrote:

Couldn't Graphs status be added to https://www.wikimediastatus.net?
Currently, it says "All Systems Operational".
It could say instead "Most Systems Operational", "Graphs extension disabled" or something.

I 've brought this comment to the attention of the cross SRE team group driving the status page forward. Thanks for the suggestion!

In T334940#8802241, @Bouzinac wrote:

Dans T334940#8802210, @C-Kobold a écrit :

Is there an easy way to just generate the Graphs locally as picture with the data from Wikidata, upload them to Wikimedia Commons and embed them again as normal picture? Could this be automated? I am not that proficient in SPARQL.

Hi, the trouble in that idea, is that the generated image might be outdated from the data input in Wikidata. Moreover, Vega is supposed to give some better end-user experience (tooltips, differents graphs, etc). Apparently, it is a matter of days to get graphs back.

The graphs I generated with data from Wikidata don't change that often (only once per year: member count of German political parties); so we could also just make normal images until this issue is resolved. At the moment, in the German Wikipedia, ALL Wikipedia pages about the major German political parties (CDU, SPD, CSU, Bündnis 90/Die Grünen, FDP, Die LINKE) have broken diagrams that were supposed to show the number of members over the years.
This is quite disastrous!

There has been no mention above of the mapping features that Graph is used for. Will the fix restore the maps that are also not showing, which use 'Graph:maps with marks'? The 'en:OSM Location map' template has 5,500 maps, and the template is also translated to 44 other languages. Thanks for the work towards fixing things.

@RobinLeicester I don't think fixing those initially will be possible. The template/lua module will likely need migrating since it's atypical in its usage of vega but it might be feasible to patch something within the extension next week.

@RobinLeicester @C-Kobold please share a URL to the template (or provide the wikitext you are using and I'll make sure to look into these as part of T335325)

@Jdlrobson Thanks, it is https://en.wikipedia.org/wiki/Template:OSM_Location_map.
This makes use of a Graph-based template at https://en.wikipedia.org/wiki/Template:Map_with_marks

@RobinLeicester I can confirm that current status is that these don't work, but you can track progress with how they currently render on https://en.wikipedia.beta.wmflabs.org/wiki/Template:OSM_Location_map and https://en.wikipedia.beta.wmflabs.org/wiki/Template:Map_with_marks and T335325 would be the appropriate ticket to follow.

I think this is also related to the Chinese strategy. Let's add him.

In T334940#8809410, @Jdlrobson wrote:

@RobinLeicester I can confirm that current status is that these don't work, but you can track progress with how they currently render on https://en.wikipedia.beta.wmflabs.org/wiki/Template:OSM_Location_map and https://en.wikipedia.beta.wmflabs.org/wiki/Template:Map_with_marks and T335325 would be the appropriate ticket to follow.

It also related to T335048

In T334940#8806363, @RobinLeicester wrote:

There has been no mention above of the mapping features that Graph is used for. Will the fix restore the maps that are also not showing, which use 'Graph:maps with marks'? The 'en:OSM Location map' template has 5,500 maps, and the template is also translated to 44 other languages. Thanks for the work towards fixing things.

In the meantime you can fix this template by moving it to https://www.mediawiki.org/wiki/Extension:Kartographer which does pretty much what your template did without using Graphs.

There is a good implemetation of Kartographer at en:template:Maplink, but it can't show any of the text labels or other items that allow a properly customised map rather than just a view into the base-map. I will have a think about whether a temporary base-map would seem better than an apology for the time being. It would be a disaster, long-term, for the maps with a lot of customisations.

The short version

• The team has laid a bunch of groundwork to add vega5 support to the graph extension and improve the extensions security overall.
• Vega5 has been enabled on the beta.cluster for testing.
• We hope the start testing on production next Tuesday on test.wikipedia.org
• Vega5 breaks a lot of graphs. The team is trying to mitigate this, but communities will need to begin migrating from vega2 to vega5.

The long version

Over the last week we have:

• added Vega5 support
• dropped support for Vega1 and Vega2
• improved the error handling messaging within the graph extension
• add logging for graph errors
• ongoing work to improve url sanitisation
• added foreign-resources infrastructure for extensions
• started work on attempting to build a rudimentary vega2->vega5 translation layer to mitigate the disruption a move to vega5 may cause
• added some support for this migration for use to update raw graph definitions (not built via lua) via the GraphSandbox
• fixed an issue with graph overflow on mobile

The graph extension has been re-enabled on the beta cluster to aid engineers in being able to test in a more production like environment rather than relying on local development environment's. We had hoped that we would be able to re-enable the graph extension with vega5 at least on test.wikipedia.org however over the past week there have been a number of challenges. Recent builds of Vega meant it did not cleanly support ES6 browsers. This was also causing problems for our infrastructure. A recent patch to vega fixed this but also saw a big update to d3.js dependencies that vega relies on.

Whilst we could have used the last deployment window to backport a bunch of work to production wiki's, the scale of what needed backporting was beyond what is reasonable for the nature of backport windows. In addition to that, we were increasingly getting close to the golden rule of don't deploy on a friday. As such the team working on this took the decision that the majority of this week's work would go out on the deployment train next week and we will look to begin further testing on test.wikipedia.org next Tuesday.

In terms of expectation management:

• The graph extension is being upgraded from vega2->vega5 which means that the graph definitions that had been previously used on wiki either in a raw form or constructed via lua modules are not compatible. This means that none of the existing graph definitions would be in any way interoperable.
• Our engineers are attempting to build a rudimentary translation layer that may provide some small degree of backward compatibility but this cannot be relied upon and it is vital that communities look to migrate graph and templates from vega2->vega5.
• The english beta wikipedia serves as a good testing location and has the most recent version of vega5 and Module:Graph from enwiki/dewiki
• This guide provides the most comprehensive detail on migration from Vega 2.

This guide provides the most comprehensive detail on migration from Vega 2.

The guide seems to be about migration from 2 to 3. Does that mean that 3 is fairly comparable with 5 and this guide is enough, or one would then need to follow guides for 3 to 4, and 4 to 5 migrations as well (assuming there are such guides)?

In T334940#8813996, @Base wrote:

The guide seems to be about migration from 2 to 3. Does that mean that 3 is fairly comparable with 5 and this guide is enough, or one would then need to follow guides for 3 to 4, and 4 to 5 migrations as well (assuming there are such guides)?

My understanding is that 3 is mostly compatible with 5. There were significantly fewer breaking changes with the jump from 3->4 and 4->5.

https://github.com/vega/vega/releases/tag/v4.0.0
https://github.com/vega/vega/releases/tag/v5.0.0

Correct - 2->3 was by far the most breaking. The following major version updates had mostly to do with the Vega lib API changes rather than the Vega syntax changes.

Change 914863 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[operations/mediawiki-config@master] Enable graphs on test wikipedia

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

Change 914863 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable graphs on test wikipedia and mediawiki.org

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

Mentioned in SAL (#wikimedia-operations) [2023-05-03T20:21:48Z] <cjming@deploy1002> Started scap: Backport for [[gerrit:914863|Enable graphs on test wikipedia and mediawiki.org (T334940)]]

Mentioned in SAL (#wikimedia-operations) [2023-05-03T20:23:18Z] <cjming@deploy1002> cjming and jdlrobson: Backport for [[gerrit:914863|Enable graphs on test wikipedia and mediawiki.org (T334940)]] synced to the testservers: mwdebug1001.eqiad.wmnet, mwdebug2001.codfw.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2002.codfw.wmnet

Mentioned in SAL (#wikimedia-operations) [2023-05-03T20:30:08Z] <cjming@deploy1002> Finished scap: Backport for [[gerrit:914863|Enable graphs on test wikipedia and mediawiki.org (T334940)]] (duration: 08m 19s)

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

[operations/mediawiki-config@master] Re-enable the Graph extension on test2wiki

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

Change 914823 merged by jenkins-bot:

[operations/mediawiki-config@master] Re-enable the Graph extension on test2wiki

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

Mentioned in SAL (#wikimedia-operations) [2023-05-04T16:44:59Z] <sbassett@deploy1002> Started scap: Backport for [[gerrit:914823|Re-enable the Graph extension on test2wiki (T334940)]]

Mentioned in SAL (#wikimedia-operations) [2023-05-04T16:46:26Z] <sbassett@deploy1002> sbassett: Backport for [[gerrit:914823|Re-enable the Graph extension on test2wiki (T334940)]] synced to the testservers: mwdebug2001.codfw.wmnet, mwdebug2002.codfw.wmnet, mwdebug1001.eqiad.wmnet, mwdebug1002.eqiad.wmnet

Mentioned in SAL (#wikimedia-operations) [2023-05-04T16:52:03Z] <sbassett@deploy1002> Finished scap: Backport for [[gerrit:914823|Re-enable the Graph extension on test2wiki (T334940)]] (duration: 07m 04s)

When Graph will be enabled on main wikis?

Will they reopen once in all wikis or will there be slow openings, x language then y language, etc?

Once more testing has taken place, there will be more answers. Patience, please. Thanks.

Will this be supported? I don't see any protocols mentioned here. Is this supported in some API instead?

"url": "tabular:///{{{table}}}",
"url": "wikidatasparql:///?query={{urlencode:{{{table}}}|PATH}}",

Those are used in [[mw:Template:Graph:Stacked]]

BTW. I've migrated Graph:PageHistory. It has an aggregate transform migration example.

There are no plans currently to port those protocols. My current recommendation would be to explore solutions that use ?action=raw. In the case where data is changing constantly, it might be worth exploring some cronjob scripts on the labs cluster that generate and dump graph JSON on wikis in an accessible form. Please let me know what challenges you run into and I'll see what we can do our side.

A simpler solution might be similar to what I did in Elasticsearch's Kibana -- the url does not have to be a string - it can be an object too. As such, it can easily be "strongly typed", e.g. "url": { "type": "tabular", "page": "{{{table}}}" }. This allows for no-escaping, easy to test approach. BTW, @Jdlrobson I had to deal with a few edge cases with fitting a graph into a box - you may want to examine the code there for that too.

Graph is temporarily disabled again on all wikis (it was only enabled on mediawiki.org and some test wikis so the change shouldn't have much user impact).

Can we have more details on the status quo? I see a restricted task added as a subtask, and if I read correctly, the graph extension is once again disabled on mediawiki.org.

Does that mean another serious security problem is discovered even with Vega 5, and we are back at the beginning?

In T334940#8847074, @MilkyDefer wrote:

Can we have more details on the status quo? I see a restricted task added as a subtask, and if I read correctly, the graph extension is once again disabled on mediawiki.org.

Does that mean another serious security problem is discovered even with Vega 5, and we are back at the beginning?

IIUC there are details about the current line of work in the newly filed T336595.

Yes we did discover new issues, and are worried that the risk of finding new vulnerabilities in Graph in the future is unacceptably high unless we change how the extension works. T336595 is a proposal for that; it shouldn't be considered a decision at this point.

Question/propsal: Due to T336595 sounding much like July (or worse)... Would it be possible to add some possibility to migrate existing charts in the meantime? For example, generate JSON of a given chart and show it in the HTML comment in the place where the chart was supposed to be displayed. So you could copy that spec, see what the graph looks like (offsite), and make an SVG, PNG, or some other substitution.

I probably could do the same manually, but for templates called from other templates, plus a Lua module on the way... That would be more complicated than a partial unlock.

@Nux you can still see the Vega JSON even if the graph is template-generated. Just copy the template invocation to [[Special:ExpandTemplates]]. The unsuppressed <graph> tag will be included in the parse result (but not in the preview).

In T334940#8848349, @Nux wrote:

Question/propsal: Due to T336595 sounding much like July (or worse)... Would it be possible to add some possibility to migrate existing charts in the meantime? For example, generate JSON of a given chart and show it in the HTML comment in the place where the chart was supposed to be displayed. So you could copy that spec, see what the graph looks like (offsite), and make an SVG, PNG, or some other substitution.

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.

May I propose disabling editing graphs (to mitigate the potential risk of someone exploiting this vulnerability, now that it's been discovered), and then leaving it up to the user if they want to view a potentially unsafe graph from before this vulnerability (which tbh I know nothing about) was discovered?

After all, a "lazy" user is just as likely to visit an unsafe site on Google, are they not?

In T334940#8850559, @gamer191 wrote:

May I propose disabling editing graphs (to mitigate the potential risk of someone exploiting this vulnerability, now that it's been discovered), and then leaving it up to the user if they want to view a potentially unsafe graph from before this vulnerability (which tbh I know nothing about) was discovered?

This is not possible in practice as graphs are embedded with the general page text which is being edited constantly - there is no way to detect when the content of a specific graph has been edited.

After all, a "lazy" user is just as likely to visit an unsafe site on Google, are they not?

General unsafe sites found via Google do not have access to the Wikimedia account of that user.

General unsafe sites found via Google do not have access to the Wikimedia account of that user.

Fair call

How about requiring users to log out to view graphs? It could show a message along the lines of "due to security issues, you must log out to view this graph"

How about requiring users to log out to view graphs?

That won't necessarily completely fix underlying problem(s) plus it's cumbersome.

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 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?

This was in reference to the idea of, getting the source of a vega template, rendering it outside of mediawiki, then uploading the resulting image to wikipedia (To work around <graph> being broken). Not about rendering wikimedia content outside of MediaWiki in general.