MediaWiki-l February 2023

mediawiki-l@lists.wikimedia.org

15 participants
13 discussions

Lis tes messages avant qu'ils ne soient effacés!
by Badoo 31 Dec '23

31 Dec '23

Lis ton message de Nganguem Victor avant qu'il ne soit effacé! Pour lire ton message, suis simplement ce lien: http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6 D'autres personnes sont aussi présentes: Oded (Tel Aviv, Israël) Priya (Udaipur, Inde) RajaYogi BK (Udaipur, Inde) Karuna (Udaipur, Inde) Chika Reginald Onyia (Pnompen', Cambodge) ...Qui d'autre? http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6 Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur. Tu as reçu cet email suite à un message envoyé par Nganguem Victor de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système. Amuse-toi bien ! L'équipe Badoo Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir: http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…

3 2

MediaWiki Extensions and Skins Security Release Supplement (1.35.9/1.38.4/1.39.1)
by Manfredi Martorana 04 Apr '23

04 Apr '23

Greetings- With the security/maintenance release of MediaWiki 1.35.9/1.38.4/1.39.1, we would also like to provide this supplementary announcement of MediaWiki extensions and skins with now-public Phabricator tasks, security patches and backports [1]: CheckUser + (T311337 <https://phabricator.wikimedia.org/T311337>, CVE-2022-39193) - Edits with the performer suppressed still show the performer in results from the CheckUser extension https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879167/ CheckUser + (T316414 <https://phabricator.wikimedia.org/T316414>, CVE-2022-39193) - Special:Investigate can expose supressed information in check results https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879166/ CheckUser + (T318166 <https://phabricator.wikimedia.org/T318166>, CVE-2022-39193) - CheckUser API can expose the suppressed performer https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879073/ GrowthExperiments + (T321733 <https://phabricator.wikimedia.org/T321733>, CVE-2023-22945) - Action=growthmanagementorlist makes it possible for blocked users to enroll as mentors https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/8… CheckUser + (T315123 <https://phabricator.wikimedia.org/T315123>, CVE-2023-22912) - CheckUser TokenManager insecurely uses AES-CTR encryption with repeated nonce, allowing an adversary to decrypt https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/879074/ MobileFrontend + (T320987 <https://phabricator.wikimedia.org/T320987>, CVE-2023-22909) - Mobile frontend's history makes really slow db queries https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/8577… Widgets + (T149488 <https://phabricator.wikimedia.org/T149488>, CVE-2023-22911) - Widgets does widget replacement in html attributes potentially leading to XSS https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Widgets/+/856035/ Wikibase + (T323592 <https://phabricator.wikimedia.org/T323592>, CVE-2023-22910) - XSS in Wikibase date formatting https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/879171/ The Wikimedia Security Team recommends updating these extensions and/or skins to the current master branch or relevant, supported release branch [2] as soon as possible. Some of the referenced Phabricator tasks above _may_ still be private. Unfortunately, when security issues are reported, sometimes sensitive information is exposed and since Phabricator is historical, we cannot make these tasks public without exposing this sensitive information. If you have any additional questions or concerns regarding this update, please feel free to contact security(a)wikimedia.org or file a security task within Phabricator [3]. [1] https://phabricator.wikimedia.org/T318974 [2] https://www.mediawiki.org/wiki/Version_lifecycle [3] https://www.mediawiki.org/wiki/Reporting_security_bugs

1 1

MediaWiki 1.40-alpha will be branched as a beta on 13 March 2023
by Tyler Cipriani 13 Mar '23

13 Mar '23

Hey all, This is a quick note to highlight that in six weeks' time, the REL1_40 branch will be created for MediaWiki core and each of the extensions and skins in Wikimedia git, with some (the 'tarball') included as sub-modules of MediaWiki itself[0]. This is the first step in the release process for MediaWiki 1.40, which should be out in May 2023, approximately six months after MediaWiki 1.39. The branches will reflect the code as of the last 'alpha' branch for the release, 1.40.0-wmf.27, which will be deployed to Wikimedia wikis in the week beginning 13 March 2023 for MediaWiki itself and those extensions and skins available there. After that point, patches that land in the main development branch of MediaWiki and its bundled extensions and skins will be slated for the MediaWiki 1.41 release unless specifically backported[1]. If you are working on a new feature that you wish to land for the release, you now have a few days to finish your work and land it in the development branch; feature changes should not be backported except in an urgent case. If your work might not be complete in time, and yet should block release for everyone else, please file a task against the `mw-1.40-release` project on Phabricator.[2] If you have tickets that are already tagged for `mw-1.40-release`, please finish them, untag them, or reach out to get them resolved in the next few weeks. We hope to issue the first release candidate, 1.40.0-rc.0, two weeks after the branch point, and if all goes well, to release MediaWiki 1.40.0 a few weeks after that. Tyler Cipriani (he/him) Engineering Manager, Release Engineering Wikimedia Foundation [0]: <https://www.mediawiki.org/wiki/Bundled_extensions_and_skins> [1]: <https://www.mediawiki.org/wiki/Backporting_fixes> [2]: <https://phabricator.wikimedia.org/tag/mw-1.40-release/>

2 1

New DB connect/query methods for MediaWiki
by Amir Sarabadani 27 Feb '23

27 Feb '23

If your code doesn't read or write to databases in MediaWiki, feel free to ignore this email. Hello, We have made changes to MediaWiki's Rdbms library that simplify and improve how to get database connections and how to perform UPDATE queries. We encourage you to adopt these and provide feedback here or via Phabricator. == 1. Get a database connection == What changed: To get a connection to the primary database, you previously needed the following: $lbFactory = MediaWikiServices::getInstance()->getDBLoadBalancerFactory(); $lbFactory->getMainLB()->getConnection( DB_PRIMARY ); And for a replica connection: $lbFactory->getMainLB()->getConnection( DB_REPLICA ); You may now adopt the simpler $lbFactory->getPrimaryDatabase() and $lbFactory->getReplicaDatabase(). In other words, instead of needing knowledge of the internal LoadBalancer, its getConnection methods, and the DB_ constants, you only call getPrimaryDatabase() or getReplicaDatabase(). We won’t deprecate LoadBalancer::getConnection() any time soon. If your code depends on other LoadBalancer methods, feel free to keep your code as-is. This change is aimed at the most common use case where you only need a database connection. The optional parameters have gotten more usable as well. getPrimaryDatabase() only takes $domain, which means you no longer need to skip over the non-applicable $groups parameter. getReplicaDatabase() takes a string for $group (instead of an array in LB::getConnection). If you maintain service classes that inject a LoadBalancer object, we recommend transitioning to inject and type against LBFactory instead. This removes exposure to LB altogether in most cases. Currently, getPrimaryDatabase/getReplicaDatabase do not yet support connection to external clusters (LB::getExternalLB). This is coming soon (see below). Reasoning: We have been reducing complexity around LB/LBF for a while (T326274 <https://phabricator.wikimedia.org/T326274>). The distinction between these is arbitrary in practice, each wears too many hats, and are not well encapsulated internally. Most importantly, LB is mostly internal to the Rdbms library. Most developers only need a connection to perform read or write queries. The added coupling can lead to mistakes, misunderstandings, and can feel overwhelming. The LB documentation includes jargon aimed at Rdbms maintainer, such as references to internal methods like isReadyForRoundOperations, setTempTablesOnlyMode, getAnyOpenConnection, appendShutdownCPIndexAsQuery, etc. The getConnection() signature is fragile and has led to major outages due to $domain being set incorrectly. E.g. if you need to connect to another wiki, you have to set $domain in *both* getMainLB() and getConnection(), otherwise *fireworks in production*. We keep this internally now to prevent future outages. Lastly, this change makes it possible to add a narrow typehint dedicated to read-only connections on replica databases, separate from primary database connections (more below). Example adoption: - https://gerrit.wikimedia.org/r/c/mediawiki/core/+/891357 - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/890… Adaption is being tracked in T330641 <https://phabricator.wikimedia.org/T330641> What is next: getPrimaryDatabase() and getReplicaDatabase() don't support "external" databases yet (e.g. x1 at WMF <https://wikitech.wikimedia.org/wiki/MariaDB#Extension_storage>). This is coming soon. Details and discussion at T330590 <https://phabricator.wikimedia.org/T330590>. In addition to reducing service dependencies to the ILBFactory typehint, we are working on an even narrower interface (that ILBFactory extends) called IConnectionProvider <https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/…> which only has four methods. It’s marked @internal for now, but that will change after we hammer out some details. == 2. IReadableDatabase typehint for replica connections == What changed: When you typehint a parameter or class member to IDatabase where a replica database is expected (DB_REPLICA), you may change it to the narrower IReadableDatabas interface. LBFactory::getReplicaDatabase returns IReadableDatabase. Reasoning: MediaWiki developers have at times performed write queries on a replica connection by mistake, which reached production. While we have effective protections against data corruption, our only option in production is to throw a fatal error, which leads to an outage. With this change we move detection to the very start of the development cycle, verified fully by static analysis in CI, regardless of test coverage! The new interface also helps you to self-document in a standard way whether your service class only reads or also writes to the database. And in IDEs we will no longer autocomplete write methods on what are known to be replica connection objects. It’ll also make the coupling between the rest of MediaWiki and extension with the rdbms library looser <https://en.wikipedia.org/wiki/Loose_coupling#In_programming>. Note that the IDatabase::query() is not part of IReadableDatabase. This method is discouraged as it executes raw SQL that may include write queries. If you call this method, continue to typehint IDatabase until you transition to safe methods like select() or SelectQueryBuilder. Example adoption: - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/8… == 3. Introducing UpdateQueryBuilder == What changed: In 2020, we introduced a chainable SelectQueryBuilder <https://www.mediawiki.org/wiki/Manual:Database_access#SelectQueryBuilder> for SELECT queries. To complement this, we now added a class called UpdateQueryBuilder, for UPDATE queries. The following existing code uses update() with unnamed positional parameters: $db->update( 'image', [ 'img_name' => 'foo' ], [ 'img_name' => 'bar' ], __METHOD__ ); You may now use the fluent style like so: $db->newUpdateQueryBuilder() ->update( 'image' ) ->set( [ 'img_name' => 'foo' ] ) ->where( [ 'img_name' => 'bar' ]) ->caller( __METHOD__ ) ->execute(); Reasoning: Similar to the SelectQueryBuilder, the fluent style is more readable. It simplifies building of conditions, is less prone to mistakes, and is more aligned with widely-used frameworks such as Doctrine (PHP) and Jooq (Java). We have had at least two data corruption incidents in production due to passing the wrong order of $set and $where condition (swapping them by mistake). This reduces the chance of such data corruptions happening, which alone was worth developing the builder for, before we get to the improved ergonomics. Example adoption: - https://gerrit.wikimedia.org/r/c/mediawiki/core/+/889627/5/includes/Categor… Adaption is being tracked in T330640 <https://phabricator.wikimedia.org/T330640>. What is next: We will continue to develop query builders for DELETE and INSERT queries. The work on migrating calls from ::select() to SelectQueryBuilder is on-going (T311866 <https://phabricator.wikimedia.org/T311866>). Thank you -- *Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Maintenance release: MediaWiki 1.39.2
by Sam Reed 22 Feb '23

22 Feb '23

I would like to announce the availability of MediaWiki 1.39.2. This release primarily is to fix various issues around database upgrades that users have reported on both MySQL/MariaDB and PostgreSQL. In the case of MySQL/MariaDB, there may have been the chance of data loss (as always, please backup before upgrading!), and page views may have resulted in an error like "The revision #0 of the page named "x" does not exist." This was seen only when upgrading in a bigger jump between versions (for example 1.31 to 1.39). More information can be seen in https://phabricator.wikimedia.org/T326071. https://phabricator.wikimedia.org/T328169 has been filed to write a maintenance script to fix the issues caused by these upgrades. It is expected this will be included in a later point release. Various patches aimed at support for PHP 8.0, 8.1, and 8.2 have been back-ported. This should fix some log spam, and MediaWiki should work fully on versions PHP 8.0 and 8.1. Reports of bugs with PHP 8.0, 8.1, or 8.2 support are particularly welcome, and fixes will be back-ported when possible. Please see https://phabricator.wikimedia.org/tag/php_8.0_support/, https://phabricator.wikimedia.org/tag/php_8.1_support/ and https://phabricator.wikimedia.org/tag/php_8.2_support/ for the relevant work boards. The tarballs have already been uploaded as of this email; the git tag has also already been pushed. == Release notes == Full release notes for 1.39.2: https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_39/RELEASE-NOTES… https://www.mediawiki.org/wiki/Release_notes/1.39 == Changes since MediaWiki 1.39.1 == * Localisation updates. * (T325872) ChangeTags: Remove table name from condition. * (T324895) MWCallbackStream: Add explicit $stream property. * (T297031, T326039) PostgresUpdater: Move setDefault ahead of changeNullableField. * (T321319) Produce HTML for invalid JSON. * (T215466, T326071) MigrateActors: Write to revision table (Follow-up 24115a8). * (T223027) ReservedUsernames config: Add reserved names from maintenance scripts. * (T325000, T324896, T307631) Updated OOUI from v0.44.3 to v0.44.5. * Remove /images .htaccess rules that are no longer relevant. * Disable php in .htaccess of images directory as a hardening measure. * (T322583) Include missing message parameter in message. * LocalFileTest: use encodeBlob/decodeBlob for img_metadata. * DatabaseSqlite: fix null blobs. * rdbms: avoid pg_escape_bytea() call-style deprecation notices. * (T322278) Improve LocalisationCache post-merge validation check. * (T324408, T326367) Updated wikimedia/remex-html from 3.0.2 to 3.0.3. * (T322278) Fix the remaining Phan failures on PHP 8.1. * (T322278, T326367) Respond to some messages from Phan on PHP 8.1. * Fix phan error when Excimer is enabled. * (T326021) Add matrix: to $wgUrlProtocols. * (T314099) stream wrapper: Declare $context class property. * (T314099) libs\jsminplus: Declare JSNode::$expression. * (T314096) composer.json: Updated composer/spdx-licenses from 1.5.6 to 1.5.7. * (T326472) Upgrading cssjanus/cssjanus (v2.1.0 => v2.1.1). * (T308536) rdbms: Remove deprecation mark for $wgSharedDB. * (T215466, T326071) installer: Split drop action out of the SQL patch for actor migration. * (T322603) SqliteMaintenance.php: Fix fatally broken instanceof check. * (T326377) rdbms: Use DBConnRef in SelectQueryBuilder. * api/en.json: api-help-datatype-expiry add missing 'may'. * (T317329) OutputPage: Fix undefined ['host'] in ImagePreconnect code. * (T328222) Pass empty string to strlen() if schema is null for PostgresDatabase. * (T289926) SpecialRevisionDelete: Set default of '' for wpReason. * (T155582, T328503) Fix XML dumps for content types with non-string getNativeData(). * (T326886) PoolCounterRedis: Fix wrong cast, locks weren't being released. * (T314099) revisiondelete: Replace dynamic property Status::$itemStatuses * (T327821) skin: Restore default 'value' attribute in makeSearchButton(). * (T329198) ParamValidator: Improve paramvalidator-help-multi-max message. * (T329415) Clear the statsd data buffer regardless of StatsdServer config. * (T292348) WikiImporter: do not fail if upload entry in dump lacks 'text' tag. * (T330049) UnregisteredLocalFile: Don't call MimeAnalyzer if no path. * (T324894 TempFSFile: Use a WeakMap for reference tracking if available. * (T295637) Add no to fallback chain of nb and nn. ********************************************************************** Download: https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gz https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.zip Download without bundled extensions: https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.tar.gz https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.zip Patch to previous version (1.39.1): https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.gz https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.zip GPG signatures: https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.tar.gz.… https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.zip.sig https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gz.sig https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.zip.sig https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.gz.sig https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.zip.sig Public keys: https://www.mediawiki.org/keys/keys.html

1 0

Soundcloud
by Richard van Berkel 15 Feb '23

15 Feb '23

Kodak black

1 0

array syntax
by rogerchrisman＠gmail.com 14 Feb '23

14 Feb '23

Hello, I have some array declarations in my LocalSettings.php from many years ago that I am worried may not be compatible with PHP 8+. When I try to run /maintenance/update.php in PHP 8.1 I get errors. It runs fine in PHP 7.4.3, fortunately. However, is it okay to set arrays like this in PHP 8+?: $wgSitemapNamespaces = array( 0, 100, 102 ); Thank you :) Roger teflpedia.com <- MediaWiki 1.39.1 recently upgraded -----example from my LocalSettings.php----- # Site Map see https://www.mediawiki.org/wiki/Manual:$wgSitemapNamespaces #$wgSitemapNamespaces = array( 0, 2, 4, 12 ); # example, to site map Main-0, User-2, Project-4, Help-12 namespace $wgSitemapNamespaces = array( 0, 100, 102 ); # let's site map ONLY Main, Essay, Lesson namespace ## Extra namespaces $wgExtraNamespaces[100] = "Lesson"; $wgExtraNamespaces[101] = "Lesson_talk"; $wgExtraNamespaces[102] = "Essay"; $wgExtraNamespaces[103] = "Essay_talk"; $wgExtraNamespaces[104] = "Debate"; $wgExtraNamespaces[105] = "Debate_talk"; ## Enable subpages in all namespaces $wgNamespacesWithSubpages = array_fill(0, 200, true); $wgNamespacesWithSubpages[NS_MAIN] = false; # per Duncan request Jan 11, 2022 ## Set default searching. Roger 2012.11.03, updated array syntax 2023.02.13 $wgNamespacesToBeSearchedDefault = [ NS_MAIN => true, NS_TALK => false, NS_USER => false, NS_USER_TALK => false, NS_PROJECT => false, NS_PROJECT_TALK => false, NS_IMAGE => false, NS_IMAGE_TALK => false, NS_MEDIAWIKI => false, NS_MEDIAWIKI_TALK => false, NS_TEMPLATE => false, NS_TEMPLATE_TALK => false, NS_HELP => false, NS_HELP_TALK => false, NS_CATEGORY => false, NS_CATEGORY_TALK => false, 100 => true, 101 => false ]; -------/example--------

6 10

[event] [crossposting] Wiki-based Business Process Tooling at NASA: The Need for Open CSP
by Erica Litrenta 08 Feb '23

08 Feb '23

The Tech Department at Wikimedia Foundation [1] invites you to a* special event on February 09, 2023, at 1600 UTC* [2]. *Richard Evans, Electronics & Data Systems Engineer At NASA Glenn Research Center *[3], will be presenting on *how MediaWiki is being used within NASA* to help manage the testing of very large spacecraft to prove they can survive the harsh conditions of launch, orbit, and re-entry. The management platform is built from MediaWiki and several key extensions that provide workflow support. This evolving platform plans to incorporate the extensions that form the MediaWiki-powered Open CSP platform [4]. This talk will explain the architecture and benefits of the NASA platform and motivate the need for Open CSP. We’ll also be recording the event to share with those who can’t make it. You can join the event through Google Meet [5]. Looking forward to seeing you there, *--on behalf of the Tech Department, Wikimedia Foundation.* *(For follow-ups, please reach out to *lnguyen(a)wikimedia.org.) [1] https://www.mediawiki.org/wiki/Wikimedia_Technology [2] https://zonestamp.toolforge.org/1675958415 [3] https://www.wikidata.org/wiki/Q618728#sitelinks-wikipedia [4] https://www.open-csp.org/Main_Page [5] https://stream.meet.google.com/stream/ce81307c-cdb7-4a5e-9697-65c423f27614 -- ________________________________ Erica Litrenta (she/her) Senior Manager, Community Relations Specialists (Product) Wikimedia Foundation

1 2

Per Namespace License
by Dennis 06 Feb '23

06 Feb '23

Hi everybody, we want to import and integrate some older MediaWiki databases (xml export / import) and shut down some old instances. For that we do want to move the content to separated namespaces. Sadly these wikis were using different licenses. Is there a way to change the license based on namespaces? Best regards, Dennis

2 1

MediaWiki API - show deleted wiki pages of 1 specific category?
by Patrick Schleizer 06 Feb '23

06 Feb '23

TLDR: Hello, is there an API feature to list deleted wiki pages but only from these which are 1 specific category prior deletion? Long: I only found API query module deletedrevisions [1], alldeletedrevisions [2], the logevents letype=delete [3] but it does not seem to have this feature. The use case is, if a wiki page was deleted in one wiki it should also be deleted in another wiki (shared content) using MediaWiki API. Kind regards, Patrick [1] https://www.mediawiki.org/w/api.php?action=help&modules=query%2Bdeletedrevi… [2] https://www.mediawiki.org/w/api.php?action=help&modules=query%2Balldeletedr… [3] https://www.mediawiki.org/wiki/API:Logevents https://www.mediawiki.org/w/api.php?action=query&list=logevents&letype=dele…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l February 2023