Could i be added to the security issue? (Mostly im curious, i used to have an interest in this extension a long time ago)

• Succinct problem statement to give context for why the review was initiated:
  • This extension has a security issue that needs to be addressed and has not been.

@Mstyles: Is 1 single open security issue really the complete list of reasons which led to creation of this ticket? If that is the logic, then probably larger parts of MediaWiki Core and numerous other extensions should also get undeployed.

If the issue is severe enough as T257062: Lilypond seemingly not subject to restrictions (CVE-2020-29007), it should be emergency disabled but reenabled once it is fixed (and there would be a task for reenable it).

Change 902388 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/mediawiki-config@master] Disable DoubleWiki extension everywhere, at least for now

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

In T332850#8721037, @Bugreporter wrote:

If the issue is severe enough as T257062: Lilypond seemingly not subject to restrictions (CVE-2020-29007), it should be emergency disabled but reenabled once it is fixed (and there would be a task for reenable it).

The bug referenced (T323651) was created in November 2022 based on the ID, if it were as serious as the Lilypond command execution issue, then it would have been disabled already.

In T332850#8721037, @Bugreporter wrote:

If the issue is severe enough as T257062: Lilypond seemingly not subject to restrictions (CVE-2020-29007), it should be emergency disabled but reenabled once it is fixed (and there would be a task for reenable it).

It's not as serious as that, but I also wouldn't call it minor or low-risk either.

In T332850#8721095, @gerritbot wrote:

Change 902388 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/mediawiki-config@master] Disable DoubleWiki extension everywhere, at least for now

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

thanks so much @Jdforrester-WMF for creating this patch. It's been rebased and the security team will try and merge and deploy today

Has anyone told the affected projects that this will happen?

@Bawolff I'm taking to comms to find out the best way to communicate with projects. Most likely will require a MassMessage to be sent out

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.

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'll talk to Maryum to understand what the framing of the message will be. I doubt that any comms can go out this week - we don't have a agreed-upon plan, it's the weekend and May 1st is a holiday in several countries. Looking forward to discussing with Maryum to figure out how to go about this all.

(@Quiddity noting my remark above that should affect the timeline. I hope I can provide a clearer green light in case this actually needs to be added to TN this week already.)

EDIT: see Maryum below.

As discussed on the private bug, there might be a reasonable, partial solution that @matmarex is willing to work on that could keep the extension enabled within production. But as I noted on the same bug, that still does not solve the issue of long-term maintenance for this extension.

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.

talking with Comms and May 1 is no longer the target week. Will come back with an update once comms are sorted out

Just a point: It's enabled in fawiki but to my knowledge we don't use it at all. Feel free to completely remove it from fawiki permanently. I always appreciate less code to maintain.

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?

In T332850#8814369, @Ladsgroup wrote:

Just a point: It's enabled in fawiki but to my knowledge we don't use it at all. Feel free to completely remove it from fawiki permanently. I always appreciate less code to maintain.

While you haven't utilised it, that is possibly an indicator that the wiki could be, and maybe should be.

I see that this extension could be well utilised for comparing two editions of a work within a wiki with some tweaking as that is essentially what the tool does.

I understand but we have a code maintenance crisis. Even if all of WMF engineering stop building any products and focus only on maintenance, we would not still be able to properly maintain the software. Currently many volunteers have stepped up in maintaining a lot of critical software and we are still having many major issues. We need to remove a lot of code to be able to properly continue and deliver (or keep the site up).

In doesn't mean this usecase isn't valid. It just means it needs a different solution. For example, you probably can use a toolforge to do the job instead in a much better way without hurting security or reliability of the core systems. If you want to, I can set it up for you. What that be okay with you?

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?

There are no public stats, however the information is collected and should be available to people who have access to wikimedia analytics cluster (aka not me anymore).

I personally agree as a general point (without talking about this task specificly) that decisions to undeploy things should be taken with eyes wide open, which should include information about how used something is. Otherwise we cannot make good informed decisions. Or for that matter communicate about it in an appropriate way.

I am doubtful that this extension gets much use as the links in the sidebar for it dont even show up anymore on wikisource afaict.

I understand but we have a code maintenance crisis. Even if all of WMF engineering stop building any products and focus only on maintenance, we would not still be able to properly maintain the software.

Personally i think the best argument for undeploying is that the extension is implemented in a sketchy way with regexes. Something that probably wouldn't be acceptable if it was written today. I don't find the maintenance argument particularly compelling because i dont think this extension has a significant impact on that (how many hours have been spent on maintaining this extension in the last 5 years? More than 1? I am doubtful. I wouldn't consider security concerns to count as maintenance as that is not really the same thing)

[This makes it sound like im opposed to undeploying, which is not the case. I just think "how many users will this affect", is a very reasonable question to ask of any breaking change, and one we should always have the answer to]

In T332850#8815530, @Bawolff wrote:

How many hours have been spent on maintaining this extension in the last 5 years? More than 1? I am doubtful. I wouldn't consider security concerns to count as maintenance as that is not really the same thing,

I would be surprised if https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DoubleWiki/+/585700 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DoubleWiki/+/781012 each took less than half an hour to write and review.

And there are even more: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DoubleWiki/+/673696 and random maint stuff that are not much on their own but add up if you have this many deployed extensions: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DoubleWiki/+/760295 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DoubleWiki/+/579777 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DoubleWiki/+/578817 (and I just went back for three years not more)

All of these add up

In T332850#8815373, @Ladsgroup wrote:

I understand but we have a code maintenance crisis. Even if all of WMF engineering stop building any products and focus only on maintenance, we would not still be able to properly maintain the software. Currently many volunteers have stepped up in maintaining a lot of critical software and we are still having many major issues. We need to remove a lot of code to be able to properly continue and deliver (or keep the site up).

In doesn't mean this usecase isn't valid. It just means it needs a different solution. For example, you probably can use a toolforge to do the job instead in a much better way without hurting security or reliability of the core systems. If you want to, I can set it up for you. What that be okay with you?

Bawolff and Pppery make interesting and probably valid comments. Though I would also agree with your commentary that this would only be a tool used very occasionally.

This tool relies on a work being available in two languages wikis and similar coding through the work, so essentially this only truly makes poetry and lyrics valid in comparison, or occasionally well-structured official documents, eg. a constitution. So I believe its value as a universal everyday tool is quite limited.

[noting that the internal WMF tools do not work as they compare raw transclusions which is the headers and the <pages> tags, rather than the transcluded products; and one cannot do this within a language.

I would think that having a toolforge alternative to allow users to make side-by-side comparison of any two works in any language would be of value, which would give considerably more versatility than the current tool. Such a tool would allow versions in the same language to be compared, be that Sherlock Holmes works, Shakespeare's sonnets, reprinted short stories, versions of constitutions, etc.

I could even see how it might be possible to code a "versions" page to display selected versions side by side, in a similar way.

Re: stats for ext:DoubleWiki based upon looking for match={langcode} in the uri query - a very quick look in turnilo at the webrequest_sampled_128 data cube gives me 102,600 hits over the past 30 days. So, very roughly, 13 million hits per 30 days. That's a decent amount for sure, though also not a lot when looking at total monthly traffic to all projects.

I'd agree with @Ladsgroup though that we are in a code maintenance crisis at this point. While the ext:DoubleWiki situation doesn't rise to the severity of the current ext:Graph situation IMO, it's the same basic cause that led to both. Having any code deployed to Wikimedia production which isn't owned by a WMF team or technical volunteer (or both) to address any variety of bug (especially security bugs) presents a very serious and very real risk to the projects.

Feel free to create a ticket for reviving DoubleWiki as a toolforge tool. I will do my best to get it done ASAP.

@Ladsgroup I agree that making DoubleWiki a toolforge tool would be a great option. Currently @matmarex has some patches out to improve the security issues and other concerns with this extension. We are looking for folks to review those patches on the task before the security team merges them. While we're waiting on the patches, we can pause any undeploy plans. Long term, I do think toolforge would be a good home for this extension.

@Mstyles: See also https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle (as task status was changed to declined) - thanks :)

Change 902388 abandoned by Jforrester:

[operations/mediawiki-config@master] Disable DoubleWiki extension everywhere, at least for now

Reason:

Done in Iba22bff997184bc4452fddc558564c9496cb8cea instead.

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

This was later done in T351675