Wikitech-l April 2017

wikitech-l@lists.wikimedia.org

81 participants
87 discussions

Start a nNew thread

Turkey ban
by Denny Vrandečić 03 May '17

03 May '17

Does it also affect the app? If so, why, and can we circumvent that?

12 12

Deprecation notice for citoid.wikimedia.org domain
by James Forrester 02 May '17

02 May '17

Hey all, The citoid service, which looks up URLs and similar strings and turns them into citations, has moved to be accessed via RESTbase as part of decommissioning the per-service domain system[0]. The old domain will stop working on *1 May 2017* (just under two months from now). In simple terms, this means that requests to citoid via citoid.wikimedia.org/api?… (*e.g.* [1]) now need to go to {wiki domain}/api/rest_v1/data/citoid/… (*e.g.* [2]) to work. End-point documentation is available in the usual place.[3] We have already moved the automatic citation feature inside the visual editor to use the domain. If you are responsible for a script, gadget, or tool which is using the old domain, please switch over before the deadline. [0] https://phabricator.wikimedia.org/T133001 [1] https://citoid.wikimedia.org/api?format=mediawiki&search=http%3A%2F%2Flink.… [2] https://www.mediawiki.org/api/rest_v1/data/citation/mediawiki/http%3A%2F%2F… [3] https://en.wikipedia.org/api/rest_v1/#!/Citation/getCitation Yours, -- James D. Forrester Lead Product Manager, Editing Wikimedia Foundation, Inc. jforrester at wikimedia.org <https://lists.wikimedia.org/mailman/listinfo/wikimedia-l> | @jdforrester

2 1

Data centre switchover to Eqiad
by zppix e 01 May '17

01 May '17

Hello, as you may or may not already know there will be a datacentre switch back to Eqiad, WMF's main data centre, on May 3rd at approximately 14:00 UTC. For approximately 20-30 minutes you will NOT be able to save edits to any WMF project. If you have any questions feel free to reply back to this email, or ask on IRC on freenode channel #wikimedia-tech. If there any major issues that occur during this time please report them to #wikimedia-tech on freenode! Thanks, Zppix Volunteer Developer for WMF www.enwp.org/User:Zppix

5 5

[MediaWiki-announce] Security release 1.27.3 and 1.28.2
by Chad Horohoe 01 May '17

01 May '17

Hello! I would like to announce the immediate availability of security releases 1.27.3 and 1.28.2. Due to a mistake in packaging, the releases 1.27.2 and 1.28.1 did not contain the fix for SyntaxHighlight_GeSHi. This new release does contain that fix. The task in question: https://phabricator.wikimedia.org/T158689 If you are not running this extension, you do not necessarily need to upgrade. Thanks, and I apologize for any confusion in the matter. Full release notes: https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_27/RELEASE-NOTES… https://www.mediawiki.org/wiki/Release_notes/1.27 https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_28/RELEASE-NOTES… https://www.mediawiki.org/wiki/Release_notes/1.28 ********************************************************************** 1.27.3 ********************************************************************** Download: https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.3.tar.gz Core only, no extensions: https://releases.wikimedia.org/mediawiki/1.27/mediawiki-core-1.27.3.tar.gz.… GPG signatures: https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.3.tar.gz.sig https://releases.wikimedia.org/mediawiki/1.27/mediawiki-core-1.27.3.tar.gz.… Public keys: https://www.mediawiki.org/keys/keys.html ********************************************************************** 1.28.2 ********************************************************************** Download: https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.2.tar.gz Core only, no extensions: https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.2.tar.gz.… GPG signatures: https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.2.tar.gz.sig https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.2.tar.gz.… Public keys: https://www.mediawiki.org/keys/keys.html _______________________________________________ MediaWiki announcements mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce

3 2

Can't open watchlist
by יגאל חיטרון 30 Apr '17

30 Apr '17

Hello. Could you help me, please? It's about 90 minutes I can't open the Special:Watchlist. Sometimes I get white screen, sometimes Wikimedia Error Request from 2.53.62.243 via cp2023 cp2023, Varnish XID 514255803 Error: 503, Service Unavailable at Sun, 30 Apr 2017 12:36:30 GMT I would file a phab ticket, but seems it's just me. The safemode=1 does not change. Thank you, Igal User:IKhitron, hewiki, Android 6.0 inner browser.

2 2

SyntaxHighlight_GeSHi in latest tarball does not include security fixes
by Brian Wolff 30 Apr '17

30 Apr '17

Hello everyone. Unfortunately there's been a mistake in generating the 1.28.1 and 1.27.2 tarball releases, where the wrong version of SyntaxHighlight_GeSHi extension was included. The version of this extension that was included has publically known severe security issues in it. Until such a time as a new release is issued (which will hopefully be soon) I reccomend that people either disable that extension or download a new version from https://www.mediawiki.org/wiki/Special:ExtensionDistributor/SyntaxHighlight… . The version of this extension in git, or from extension distributor is fine. Only the version in the most recent tarball is wrong. The rest of the release is also fine. The 1.23.16 and 1.23.17 release was not affected by this issue. Sorry for the confusion, -- Brian

1 0

Proposal to deprecate parsing and diffs in the action API action=query&prop=revisions
by Brad Jorsch (Anomie) 29 Apr '17

29 Apr '17

TL;DR: I'm proposing deprecating a bunch of parameters. See https://phabricator.wikimedia.org/T164106. In the action API, there are two ways to parse a page/revision: using action=parse, or using the rvparse parameter to action=query&prop=revisions. Similarly, there are two ways to get a diff: using action=compare, or using parameters such as rvdiffto to action=query&prop=revisions. And then there's action=expandtemplates versus the rvexpandtemplates parameter to prop=revisions. This is a somewhat annoying bit of code duplication. Further, the prop=revisions versions of these features have somewhat strange behavior. rvparse forces rvlimit=1. rvdiffto and related parameters will sometimes output "notcached" with no way to directly handle the situation. So, I propose deprecating all of these parameters. The parameters that would be deprecated are the 'rvdifftotext', 'rvdifftotextpst', 'rvdiffto', 'rvexpandtemplates', 'rvgeneratexml', 'rvparse', and 'rvprop=parsetree' parameters to prop=revisions, and the similarly named parameters to prop=deletedrevisions, list=allrevisions, and list=alldeletedrevisions. Following the normal action API deprecation policy, they'd output warnings but would continue to function until usage drops sufficiently or until it becomes too much trouble to fix them, and they wouldn't receive new feature development. If anyone would object to this plan, please reply at https://phabricator.wikimedia.org/T164106, or here if you really hate Phabricator. If there aren't major objections, I'll probably do the deprecation in the next week or two. Thanks. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

1 0

ArchCom Radar, 2017-04-26
by Daniel Kinzler 29 Apr '17

29 Apr '17

Hi all! Here are the minutes from this week's ArchCom meeting. You can also find the minutes at <https://www.mediawiki.org/wiki/Architecture_committee/2017-04-26>. See also the ArchCom status page at <https://www.mediawiki.org/wiki/Architecture_committee/Status> and the RFC board <https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>. Here are the minutes, for your convenience: * “Canonical data URLs” has been approved: https://phabricator.wikimedia.org/T161527 * “Deprecate unserialize” goes to final call: https://phabricator.wikimedia.org/T161647 * “Long revision comments” to be discussed next Wednesday (May 3), pending confirmation from Kaldari: https://phabricator.wikimedia.org/T153333 Active RFCs: * JS packages / dependency management: some work on implementation https://phabricator.wikimedia.org/T107561 * Multi-file resources: some discussion https://phabricator.wikimedia.org/T133462 Also, discussion started about major overhaul of the the database schema, particularly the revision table. See https://gerrit.wikimedia.org/r/#/c/350097/ and https://phabricator.wikimedia.org/T161671 and https://www.mediawiki.org/wiki/User:Brion_VIBBER/Compacting_the_revision_ta… for context. -- Daniel Kinzler Principal Platform Engineer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

1 0

Final Call for comments: Deprecate using PHP serialization inside MediaWiki
by Daniel Kinzler 28 Apr '17

28 Apr '17

This is a final call for comments on <https://phabricator.wikimedia.org/T161647>, "Deprecate using PHP serialization inside MediaWiki". This RFC has seen quite a bit of discussion on Phabricator, but has not been discussed in an IRC meeting. ArchCom feels that the discussion was already quite fruitful, and only minor issues are left to resolve. It was agreed that the RFC be put on Final Call: if no new concerns are raised and remain open by May 10, the RFC will be approved for implementation. The RFC in full: Problem statement PHP unserialize() and serialize() can execute code when given malicious input. In most cases this serialization format is unnecessary. As a hardening measure against making a mistake that could result in remote code execution, we should avoid this format. Proposed guideline This RFC proposes the following: * New code SHOULD use JSON instead of PHP serialization whenever possible. * Serialization of primitive values and key-value structures MUST never use PHP serialization. * Any edge cases that require use of serialize or unserialize complicated classes, MUST protect the serialized blob with HMAC (e.g. keyed to $wgSecretKey) to protect against malicious modifications of the blob. In addition to the new guideline for new code, this RFC proposes that we start to (slowly) convert existing uses of PHP serialization. Most likely by using JSON. The eventual goal being to remove all legacy uses of php unserialize() Good first candidates for conversion: * LocalisationCache * MediaHandler metadata. The php serialization output format of the API is outside of the scope of this RFC, since we never ingest it. -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

1 0

Final Call for comments: RFC Canonical data URLs for machine readable page content
by Daniel Kinzler 28 Apr '17

28 Apr '17

This is a final call for comments on <https://phabricator.wikimedia.org/T161527>, "Canonical data URLs for machine readable page content". This RFC was discussed in a public RFC meeting on the wikimedia-office channel on April 12. It was agreed that the RDF be put on Final Call: if no new pertinent concerns are raised by April 26th, the RFC will be approved for implementation. Meeting log: <https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.20…> The RFC has been discussed before, and proöposed for final call, but some new concerns where indeed raised, which were then addressed in the above discussion. Log of the original meeting: <https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.20…> The RDF proposes: * Use URLs of the form https://commons.wikimedia.org/data/main/Data:Avignon_City_Wall.map to identify and retrieve machine readable page content. "main" refers to the main slot, see T107595. * The /data/<slot> path is rewritten to a special page, Special:PageData * Special Special:PageData will redirect (with status 303) to an appropriate (and typically cacheable) URL for retrieving the page data. For now, this will use the action=raw interface. * Special:PageData may apply content negotiation based on the Accept header sent by the client. In the first iteration, it will only check if any accept header sent by the client is compatible with the content model of the requested page. * The 303 redirects are not cecheable for now, because they depend on the Accept header; complex normalization would be needed to allow the cache to vary on the Accept header without causing massive cache fragementation. Please see the phabricator ticket for a summary of the concerns raised and addressed. -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

1 2

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

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 April 2017