Wikitech-l September 2023

wikitech-l@lists.wikimedia.org

38 participants
33 discussions

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 18 Jun '24

18 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

2 2

[action requested] Technical Decision-Making Retrospective Survey
by Moriel Schottlender 23 Apr '24

23 Apr '24

Hello all, The Technical Decision-Making Forum Retrospective team <https://www.mediawiki.org/wiki/Technical_decision_making> invites you to complete a survey about Wikimedia's technical decision-making processes. While there will be more ways to participate, this is the first and most important step in our data collection. It aims to gather information about your experience, thoughts, and needs regarding the process of making technical decisions across the Wikimedia technical spaces. This survey will be used for gathering information about the process and the needs around technical decision-making that touches our production systems. You can find the survey link here: https://wikimediafoundation.limesurvey.net/885471?lang=en Who should take this survey? People who do technical work that relies on software maintained by the Wikimedia Foundation (WMF) or affiliates. If you contribute code to MediaWiki or extensions used by Wikimedia, or you maintain gadgets or tools that rely on WMF infrastructure, this survey is for you. What is the deadline? *August 7th, 2023 * What will the Retrospective team do with the information? The retrospective team will synthesize the collected data and publish an anonymized analysis that will help leadership make decisions about the future of the process. We will collect anonymized information that we will analyze in two main ways: - Sentiments based on demographic information: these will tell us whether there are different needs and desires from different groups of people. - General needs and perceptions about decision-making in our technical spaces: This will help us understand what kind of decisions happen in the spaces, who is involved, and how to adjust our processes accordingly. Is the survey the only way to participate? The survey is the most important way for us to gather information because it helps us gather input in a structured manner. But it will not be the only way you can share your thoughts with us - we will have more information soon about upcoming listening sessions where you can talk with us live. In the meantime, you are always welcome to leave feedback on the talk page: https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Technical_Dec… Where can I see more information? There are several places where you can find more information about the Technical Decision-Making Process Retrospective: - The original announcement about the retrospective from Tajh Taylor: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/… - The Technical Decision-Making Process general information page: https://www.mediawiki.org/wiki/Technical_decision_making - The Technical Decision-Making Process Retrospective on MediaWiki: https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision… - Phabricator ticket: https://phabricator.wikimedia.org/T333235 How to contact the retrospective core team: - Write to the core team mailing list: tdf-retro-2023(a)lists.wikimedia.org - The Technical Decision-Making Process Retrospective on MediaWiki talk page: https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Technical_Dec… Thank you, Moriel, on behalf of the TDMP Retro Core Group Core group: - Moriel Schottlender (chair) - Daniel Kinzler - Chris Danis - Kosta Harlan - Temilola Adeleye -- Moriel Schottlender (she/her <https://pronoun.is/she>) Principal Software Engineer Wikimedia Foundation https://wikimediafoundation.org/

3 6

SemanticCite
by Sorin Gheorghiu 30 Oct '23

30 Oct '23

Hello folks! does anybody know if this extension is still maintained? The latest commit is from May 16, 2020. There are older tickets about SCI being not compatible with SWM 4.0.0 (and therefore not compatible with MW1.39 which will become EOL end of 2023). Sorin

4 3

Announcing: Path review board
by Brian Wolff 04 Oct '23

04 Oct '23

Yesterday there was a conversation about code review on irc and among other things, how sometimes patches can get "stuck". I had an idea for a way to improve things. I'm not sure if it is a good idea, but there's only one way to find out. So without further ado, announcing the Code Review Patch Board: https://www.mediawiki.org/wiki/Code_review/patch_board In short - each person is allowed to list one of their patches on the board that they would really like to see reviewed. You can only list one patch at a time, and it should be a patch that you have been unable to get review for for at least a week through normal means. See the page for the full list of guidelines. I encourage people to give it a try. Add a patch you wrote that you cannot get a review for. Or if you have +2 rights, try giving some love to these underloved patches. I would also love to hear feedback on the general idea as well as the current guidelines. To repeat, the url is: https://www.mediawiki.org/wiki/Code_review/patch_board Thanks, bawolff

4 5

Talk to the Search Platform / Query Service Team—October 4, 2023
by Guillaume Lederrey 04 Oct '23

04 Oct '23

Hello all! The Search Platform Team usually holds an open meeting on the first Wednesday of each month. Come talk to us about anything related to Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query Service (WCQS), etc.! Feel free to add your items to the Etherpad Agenda for the next meeting. Details for our next meeting: Date: Wednesday, October 4, 2023 Time: 15:00-16:00 UTC / 08:00 PT / 11:00 EDT / 17:00 CET Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours Google Meet link: https://meet.google.com/vgj-bbeb-uyi Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927 Have fun and see you soon! Guillaume -- *Guillaume Lederrey* (he/him) Engineering Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

New developer feature: $wgUseXssLanguage / x-xss language code
by Lucas Werkmeister 02 Oct '23

02 Oct '23

Hi all! This is an announcement for a new developer feature in MediaWiki. If you don’t develop MediaWiki core, extensions or skins, you can stop reading :) MediaWiki interface messages are generally “safe” to edit: when they contain markup, it is either parsed (as wikitext), sanitized, or fully HTML-escaped. For this reason, administrators are allowed to edit normal messages on-wiki in the MediaWiki: namespace, while editing JS code (which is more dangerous) is restricted to interface administrators. (A few exceptions, messages that are not escaped and which can only be edited by interface administrators, are configured in $wgRawHtmlMessages <https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:$wgRawHtmlMessages>.) Occasionally, a bug in the software means that a message isn’t properly escaped, which can in theory be abused by administrators to effectively gain interface administrator powers (by editing a MediaWiki: page for a message to contain <script> tags, or onclick="" attributes, or whatever). Such bugs are usually considered low-severity security issues; some of them are tracked in T2212 <https://phabricator.wikimedia.org/T2212>. (The general issue is known as cross-site scripting <https://www.mediawiki.org/wiki/Special:MyLanguage/Cross-site_scripting> and can be much more severe when it’s not limited to interface messages.) Previously, checking for these issues as a developer was tedious: if you suspected that a message was vulnerable to HTML injection, you had to create a page for it in the MediaWiki: namespace, or edit the corresponding en.json file on disk (and potentially rebuild the localisation cache). The recently merged “xss language code” feature simplifies this process. If the developer setting $wgUseXssLanguage is set to true, then an “x-xss” language code becomes available and can be selected with *?uselang=x-xss* in the URL. When using this language code, all messages become “malicious”: every message is replaced by a snippet of HTML that tries to run alert(' *message-key*'). If everything is implemented correctly, all of those HTML snippets should be escaped, and no alerts should fire, although the wiki will look quite strange: If you see any alert, then that means that a message has not been escaped correctly; use the message key shown in the alert to hunt down the buggy code (or add the message key to $wgRawHtmlMessages). This feature is intended to be especially useful during code review: check out the change, load a page with ?uselang=x-xss, and see if any alerts come up. Miscellaneous notes: - This is a developer-only feature. I strongly recommend against setting $wgUseXssLanguage = true; in any production setting. (It will be added to DevelopmentSettings.php soon.) - Above, I focused on the possibility to abuse unescaped messages via the MediaWiki: namespace. You might also be thinking about the potential for translatewiki.net contributors to inject malicious HTML into message translations; however, the translation exports from translatewiki.net to the JSON files automatically check for any HTML in translations, and flag suspicious cases for human review. Therefore, it’s much harder to exploit an unescaped message via translatewiki.net than via the MediaWiki: namespace. - Finally, I should mention that we already found several vulnerabilities using this feature, which will be fixed with the upcoming security release <https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>. If you try out this feature now, and find a vulnerable message, I suggest you wait until then, and check whether it’s still vulnerable, before reporting it. Cheers, Lucas -- Lucas Werkmeister (he/er) Software Engineer Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30-577 11 62-0 https://wikimedia.de Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

3 3

Wiki content and other dumps new ownership, feedback requested on new version!
by Ariel Glenn WMF 30 Sep '23

30 Sep '23

Hello folks! For some years now, I've been the main or only point of contact for the Wiki project sql/xml dumps semimonthly, as well as for a number of miscellaneous weekly datasets. This work is now passing to Data Platform Engineering (DPE), and your new points of contact, starting right away, will be Will Doran (email:wdoran) and Virginia Poundstone (email:vpoundstone). I'll still be lending a hand in the background for a little while but by the end of the month I'll have transitioned into a new role at the Wikimedia Foundation, working more directly on MediaWiki itself. The Data Products team, a subteam of DPE, will be managing the current dumps day-to-day, as well as working on a new dumps system intended to replace and greatly improve the current one. What formats will it produce, and what content, and in what bundles? These are all great questions, and you have a chance to help decide on the answers. The team is gathering feedback right now; follow this link [ https://docs.google.com/forms/d/e/1FAIpQLScp2KzkcTF7kE8gilCeSogzpeoVN-8yp_S…] to give your input! If you want to follow along on work being done on the new dumps system, you can check the phabricator workboard at https://phabricator.wikimedia.org/project/board/6630/ and look for items with the "Dumps 2.0" tag. Members of the Data Products team are already stepping up to manage the xmldatadumps-l mailing list, so you should not notice any changes as far as that goes. And as always, for dumps-related questions people on this list cannot answer, and which are not covered in the docs at https://meta.wikimedia.org/wiki/Data_dumps or https://wikitech.wikimedia.org/wiki/Dumps you can always email ops-dumps (at) wikimedia.org. See you on the wikis! Ariel Glenn ariel(a)wikimedia.org

5 4

MediaWiki Insights - second monthly email
by Birgit Müller 29 Sep '23

29 Sep '23

Hello All, Welcome to the second edition of the monthly MediaWiki Insights <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports> email! Since the beginning of July, the Foundation has dedicated MediaWiki product leadership and a new MediaWiki engineering group <https://www.mediawiki.org/wiki/MediaWiki_Engineering_Group>. In August <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/August_20…>, we’ve shared a broad overview on the focus for the next few quarters: 1. Building up the new MW Engineering group and MW Product function 2. Developing a strategy for MediaWiki - by June 30th, 2024 [WMF Annual Plan, WE3 <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/…> ] 3. Reaching a 20% increase of authors to selected MediaWiki repositories deployed in Wikimedia production - by June 30th, 2024 [WE3.2] 4. Investing in developer experiences and reduce fragmentation of developer workflows [WE 3.1] - continuous work with specific deliverables in 2023/24 5. Exploring and resolving a set of questions around stewardship and Open Source strategy (goes beyond MediaWiki) [WE3.3] We’re still in the process of “settling in” (1.), but also made progress on a few things that we wanted to start tackling early: Stewardship We’ve had conversations within the MediaWiki Engineering group <https://www.mediawiki.org/wiki/MediaWiki_Engineering_Group> on which components we should prioritize initially/own directly and what the things are that we’d primarily provide guidance on. While this is work in progress and also touches on bigger questions, one notable decision is that MW Engineering takes on stewardship for the authentication-related components (in MW core and extensions), with support from the Security team. We’ve resolved outstanding code stewardship requests for the CentralAuth <https://phabricator.wikimedia.org/T252244> and Oauth <https://phabricator.wikimedia.org/T224919> extensions as a consequence of this decision. These changes and other updates are reflected on the developers and maintainers page <https://www.mediawiki.org/wiki/Developers/Maintainers> on MW.org. MediaWiki within Wikimedia’s ecosystem: Update on interviews So far we’ve interviewed about 40 people on their experiences with MediaWiki within Wikimedia’s ecosystem and plan a few more interviews. We expect to be able to wrap up this first round of research in October and to share the outcome and conclusions in November. These conversations have been incredibly helpful - many thanks to all the people who took the time to share their thoughts or still will do so <3 You can find a tentative timeline and overview on research planned throughout the next few quarters on this page <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights#Research_pillars_…> . Project snapshot: Source Maps and top-level autologin Over the past few weeks, the MediaWiki Engineering group has been working on a mix of onboarding tasks (i.e. ResourceLoader, ActionAPI, CentralAuth), production errors, long term initiatives (Parsoid Read Views, RESTBase deprecation), consultancy, code review for staff and volunteers’ patches, and completed projects that had been in the making for a while. A few snapshots: Source Maps <https://web.dev/source-maps/> aim to make debugging in web development easier. It’s a technique for mapping combined and minified JavaScript back to the original files. Support for source maps is now implemented in ResourceLoader <https://www.mediawiki.org/wiki/ResourceLoader>, to aid with debugging ResourceLoader in production. You can learn more about this work in this ticket. <https://phabricator.wikimedia.org/T47514> <3 to Tim, Timo and others for their work on this! Browsers increasingly roll out anti-tracking measures and limitations on third-party cookie use. An unfortunate side effect of this is that it also impacts CentralAuth autologin. One way to mitigate the effects and to allow auto-login when the browser blocks third-party cookies is to attempt central auto-login via top-level navigation. This has been enabled in September. You can learn more about this work in this ticket <https://phabricator.wikimedia.org/T326281>. <3 to Gergö and others for the work on this! Onboarding, among other means, has continued via the weekly Code Mob sessions: Check out the recordings on this page <https://meta.wikimedia.org/wiki/User:BPirkle_(WMF)/Code_Mobs_2023> if you want to follow along. Next: Enable more people to know MediaWiki and contribute effectively A key question this year is how we can grow the number of people willing and able to contribute to MediaWiki. So far we’ve explored approaches and focus areas, turned some aspects of this already into active practice through code review and consultancy for teams whose projects touch MediaWiki core; and came up with first ideas that may help new MediaWiki contributors (example <https://phabricator.wikimedia.org/T347347>). We’ll be sharing more about this work and possible initiatives in October, which is when we “officially” start with working towards an increase of authors across a specific set of MW repositories that are deployed to production (WMF Annual Plan, WE3.2 <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/…> ). Thanks all for reading! - Have a great weekend, Birgit -- Birgit Müller (she/her) Director of Product, MediaWiki and Developer Experiences Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Re: New developer feature: $wgUseXssLanguage / x-xss language code
by Yaron Koren 29 Sep '23

29 Sep '23

> > If the developer setting $wgUseXssLanguage is set to true, then an “x-xss” > language code becomes available and can be selected with *?uselang=x-xss* > in the URL. When using this language code, all messages become “malicious”: > every message is replaced by a snippet of HTML that tries to run alert(' > *message-key*'). Clever feature - this will be great for testing. Thank you! -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com

1 0

Maintenance release: MediaWiki 1.35.13
by Sam Reed 29 Sep '23

29 Sep '23

I would like to announce the availability of MediaWiki 1.35.13 This fixes an issue identified in the MediaWiki 1.35.13 release. The patch for T341529 was incorrectly back-ported, which would result in an error relating to some diffs. If you use git tags, 1.35.12 and 1.35.13 are basically identical (bar RELEASE-NOTES and a version bump), due to how the issue was resolved to get the patches through CI. If you use the tarballs and patches, as the patches are created against the uploaded tarballs (not re-created versions from the git tags), the patch will resolve the issue mentioned above. ********************************************************************** Download: https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.13.tar.gz https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.13.zip Download without bundled extensions: https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.13.tar.gz https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.13.zip Patch to previous version (1.35.12): https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.13.patch.gz https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.13.patch.zip GPG signatures: https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.13.tar.gz… https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.13.zip.sig https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.13.tar.gz.sig https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.13.zip.sig https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.13.patch.gz.sig https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.13.patch.zip.s… Public keys: https://www.mediawiki.org/keys/keys.html

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l September 2023