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.
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.
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2017.04. This bundle is The bundle is compatible with MediaWiki
1.27 and 1.28 or above and requires PHP 5.5.9 or above.
Next MLEB is expected to be released in 3 months. If there are major
changes or important bug fixes, we will do intermediate release.
Please give us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2017.04.tar…
* sha256sum: 4207398d7ed3ea9c793f35f88e75f29672b33aee4d0baf01afc869517c629c65
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Highlights and upgrade notes ==
== Babel ==
* TTO fixed disappearing language names on Category: and File: pages.
== CLDR ==
* Reedy updated to CLDR 31.
== CleanChanges, LocalisationUpdate ==
* Localisation updates only.
== Translate ==
* Bartosz Dziewoński fixed "Mark as reviewed" tooltip positioning.
* David Causse added support for Elastic5, Multi-DC for TTMServices,
freezing writes.
* Federico Leva fixed import of the new translations in
Special:ImportTranslations.
* Geoffrey Mon added insertables suggester class for $1, $2 and allow
multiple suggesters.
* MarcoAurelio modified log message to match with all other logs
listed in Special:Log.
* Niklas Laxström added support to allow moving all pages for
translation admins (translate-manage).
* TTO updated translator-stats to account for expiring user groups.
* datguy added confirmation box in Special:ManageTranslatorSandbox
when approving or rejecting a translator. (T60706)
== UniversalLanguageSelector ==
* Bartosz Dziewoński fixed language change tooltip position. (T161203)
* Niklas Laxström added link to Compact Language Links info page in
the beta feature description.
* Niklas Laxström fixed broken site picks feature for Compact Language
Links. (T157344)
=== Fonts ===
* Kartik Mistry added Sundanese (su) font. (T162221)
=== Input methods ===
* Amir Aharoni fixed name of Arabic keyboard.
* Amir Aharoni and Felix Nartey added keyboard for Ga language.
* Amir Aharoni added Akan keyboard also for Twi language.
* fgaim added new IMEs for Eritrean languages: Tigrinya (ti), Tigre
(tig), Blin (byn).
* WikiDiscoverer fixed autonym for Gõychi Konknni (gom) language.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Hey,
One common form of vandalism in Wikidata is removing sitelinks (we already
have an abuse filter flagging them).
One of my friends in Persian Wikipedia (who is not a wikidata editor and
only cares about Persian Wikipedia) asked me to write a tool that lists all
Persian Wikipedia sitelink removals. So I wrote something small and fast
but it's usable for any wiki. For example English Wikipedia:
http://tools.wmflabs.org/dexbot/tools/deleted_sitelinks.php?wiki=enwiki
It's slow due to nature of the database query but once it responds, you
might find good things to revert.
Since this is the most useful for Wikipedia editors who don't want to
patrol Wikidata (in that case, this query
<https://www.wikidata.org/w/index.php?namespace=&tagfilter=new+editor+removi…>
is
the most useful) I'm reaching to wider audiences. Sorry for spamming.
HTH
Best
Hi,
What it says in the subject :) I've made the REL1_29 branch from master (as
of 273eea7357c546d1a1aafd73320e10e8ddac79eb) and have bumped the version to
1.29.0-rc.0 (from alpha). All extensions, skins and vendor have been
branched as well.
I've just landed the change to master that bumps it to 1.30.0-rc.0.
Let the backports begin! (I want to be generous this time too, so bring 'em
at me)
-Chad
https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-04-26
*= 2017-04-26 = *
contact: https://www.mediawiki.org/wiki/Wikimedia_Engineering
== Call outs:==
* Datacenter switch back Wednesday, May 3rd 2017 14:00 UTC (user visible,
requires read-only mode)
** https://wikitech.wikimedia.org/wiki/Switch_Datacenter
* RelEng/Ops: Reading Web needs your help! Config is being ignored and
shipping feature that communities have explicitly asked to be disabled and
we don't understand why. https://phabricator.wikimedia.org/T163114
== Product ==
=== Reading ===
==== Web ====
* Mostly bug fixing and improving code quality for pending Page previews
launch
* Need help from RelEng/Ops to address `Regression: Fix config to disable
related pages where it's not wanted(
https://phabricator.wikimedia.org/T163114)`. Config is being ignored and
shipping feature that communities have explicitly asked to be disabled and
we don't understand why.
==== iOS ====
* Last Week
** Continued work on 5.4.1 -
https://phabricator.wikimedia.org/project/view/2600/
*** Regression testing, new public beta
*** Crash fixes & performance enhancements
** 5.5 - https://phabricator.wikimedia.org/project/view/2602/
*** Places (UserTesting feedback)
*** Article footer content rendered in HTML/CSS rather than native views
* This Week
** Submit 5.4.1 to the App Store
** Continue work on 5.5
*** Updates to Places from user feedback
==== Android ====
* Beta released last week containing Wikidata title description editing
expanded to many more languages, as well as various offline UX improvements
** Hotfix release Friday (4/21), promoted to prod yesterday:
https://lists.wikimedia.org/pipermail/mobile-l/2017-April/010503.html
* Planning is underway for implementing offline ZIM compilations (Q4 goal)
** https://phabricator.wikimedia.org/project/view/2723/
* Continuing work on cross-platform consolidation of CSS & JS
* Current release board:
https://phabricator.wikimedia.org/project/view/2352/
==== Reading Infrastructure ====
* ORES: working on api.php abuse + DB size issues, hoping to reenable after
data center switchback
* librarized https://www.mediawiki.org/wiki/Testing-access-wrapper
* MCS: stop annoucement of past survey, fix handling of links in section
titles
=== Editing ===
==== UI Standardization ====
* This week:
** Continued work to provide WikimediaUI Base variables in core
https://phabricator.wikimedia.org/T123359
* Updates:
** OOjs UI:
*** Release of v0.21.2 with 11 UI/a11y improvements
https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md –
among those:
**** MediaWiki theme: Full WCAG level AA contrast support of widgets
accomplished
**** MediaWiki theme: Fix IE 7 oversized buttons
**** MediaWiki theme: Improve SearchWidget design
**** Set ARIA `role=combobox` on DropdownWidget and LookupElement too
(Bartosz Dziewoński)
**** Set `aria-owns` for everything with a dropdown list (ARIA
`role=combobox`) (Bartosz Dziewoński)
==== Parsing ====
* Parsoid: Audio / video support in place -- we plan to deploy today.
* Linter: Improved documentation and guidance for fixing linter errors @
https://www.mediawiki.org/wiki/Help:Extension:Linter
* Tidy replacement: Updated documentation @
https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy/FAQ
* Language Variant tweaks in preprocessor: Fixups required documented @
https://www.mediawiki.org/wiki/Parsoid/Language_conversion/Preprocessor_fix…
...
an editor has been diligently fixing them. We plan to make an announcement
about this upcoming change soon and then merge the core patch (
https://gerrit.wikimedia.org/r/#/c/333997/ ) after that.
==== Language ====
* CX reenabled; We're watching logs and ready to disable if needed.
Incident report in progress.
** https://phabricator.wikimedia.org/T163344
* OOjs UI migration work in progress.
==== Collaboration ====
* RCFilters: Optimization so if we know a query will return 0 results, we
won't do the query at all. Some of these no-result queries have extremely
poor performance.
* Working on GuidedTour to make people aware of RCFilters beta feature
* Working on next generation of RCFilters, including namespace and user
filters, saved settings, and more sophisticated time filtering.
* DId a deploy Monday to enable RCFilters on English Wikipedia, plus almost
all non-ORES wikis. Some issues with preferences, but these have been
partly tracked down.
* Other bug fixes
=== Community Tech ===
No blockers
* Rollling out Cookie Blocking to all wikis next Monday
* Further polish work on CodeMirror extension (syntax highlighting)
* Getting community feedback on LoginNotify extension (currently on Beta
Cluster for testing)
* User rights expiration is live on all wikis
== Technology ==
=== Research ===
* Reader research surveys are most likely to go out next week
** We will be running these surveys in 14 languages with the help of
Reading team
**
https://meta.wikimedia.org/wiki/Research_talk:Characterizing_Wikipedia_Read…
** https://phabricator.wikimedia.org/T151835
== Wikidata ==
* Focusing on the Lexeme extensions UI, example:
http://wikidata-lexeme.wmflabs.org/index.php/Lexeme:L2
* Had to work around a change in core that blocked undeleting Wikidata
entities: https://phabricator.wikimedia.org/T163144
* Going to deploy Echo notifications when linking pages via Wikidata:
https://phabricator.wikimedia.org/T110604
== German Technical Wishlist ==
* Planning next steps for the book referencing wish:
https://phabricator.wikimedia.org/T151301
=== Discovery ===
* No blockers
* Building infrastructure for machine learning assisted ranking (aka
MjoLniR)
* Chinese analyzer seems to be doing well, enabling soon. Working on Hebrew
analyzer.
* Completed analysis of second sister wiki search A/B test:
https://commons.wikimedia.org/wiki/File%3ASecond_Test_Of_Cross-wiki_Search_…
* Published notes from discussion on scoring functions:
https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Some_Thoughts_on_the…
* Updated WDQS dashboard to include traffic from all SPARQL endpoints:
https://discovery.wmflabs.org/wdqs/
* Updated the external search dashboard to display non-bot traffic (
https://discovery.wmflabs.org/external/, task T161932)
* Portal statistics (task T128546) and translations (task T142582) were
updated
* Working on Wikidata search improvement
* Working on Mediawiki API integration for WDQS
=== Analytics ===
* Ongoing work on EventLogging analysis support in Hadoop - Not yet finished
* Ongoing work on Wikistats 2.0 data back-end - Finalizing Design
* Started to define webrequest tagging project
* Daily uniques are in Pivot http://bit.ly/2oZU5gt
* Waiting for feedback on Wikistats 2.0 consultation
* Dashiki configuration articles on meta still broken, can't fix them until
the codfw-related deployment moratorium is over
=== TechOps ===
* '''Blocked'''
** None
* '''Blocking'''
** None?
* '''Updates'''
** Wrapping up switchover action items
https://etherpad.wikimedia.org/p/codfw-switchover-AprMay2017
** ToolsProxy incident report
https://wikitech.wikimedia.org/wiki/Incident_documentation/20170419-ToolsPr…
=== Security ===
* Reviews
** WikibaseMediaInfo
** TemplateStyles
=== Services ===
* Blockers: none
* Updates:
** Service-runner doesn't support node 0.1x any more
*** https://github.com/wikimedia/service-runner/pull/163
=== RelEng ===
* '''Blocked'''
** None
* '''Blocking'''
** None?
** Config symlinks should be touched when they're deployed, Reading callout
above https://phabricator.wikimedia.org/T126306
* '''Updates'''
** New version of scap out
https://github.com/wikimedia/scap/blob/release/debian/changelog#L1 (config
diffs in a basic format, env announce in IRC)
** 1.29 is coming...see wikitech email for more info
=== Fundraising Tech ===
* More Paypal Express Checkout fixes
* Investigating potential extra session creation on paymentswiki
* Planning Ingenico integration changeover, which will include moving a lot
of functionality from MW extension to lib
* Coordinating with Comms to update the WMF logo in various places:
https://phabricator.wikimedia.org/T144254
* CentralNotice: Banner sequence feature is in code review
https://phabricator.wikimedia.org/T144453
* CiviCRM: getting rid of the rest of our local core hacks, using upstream
buildkit in CI
* Found a dozen repos we can delete
I'm having an issue with getting ResourceLoader to properly load the
Masonry library [1]. This issue was not present on MW 1.25 but is on MW
1.27. If I do the following:
$out->addModules( 'ext.masonrymainpage.libs' ); // or as dependency to base
$out->addModules( 'ext.masonrymainpage.base' );
Then I get the following error in my browser:
Uncaught Error: Module "jquery" is not loaded.
at require
(load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ciafJ7Ly:12581)
at masonry.pkgd.js?c5dde:29
at masonry.pkgd.js?c5dde:39
require @
load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ciafJ7Ly:12581
(anonymous) @ masonry.pkgd.js?c5dde:29
(anonymous) @ masonry.pkgd.js?c5dde:39
load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ciafJ7Ly:11145
Use of "wgCategories" is deprecated. Use mw.config instead.
get @
load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ciafJ7Ly:11145
(anonymous) @
load.php?debug=true&lang=en&modules=site&only=scripts&skin=vector&version=680c78b07fb0:273
However, if I load Masonry not from the ext.masonrymainpage.libs module,
but instead using OutputPage::addScript() then I have no issues:
global $wgServer, $wgExtensionAssetsPath;
$scriptURL =
"$wgServer/$wgExtensionAssetsPath/MasonryMainPage/masonry.pkgd.js";
$out->addScript( "<script type='text/javascript'
src='$scriptURL'></script>" );
$out->addModules( 'ext.masonrymainpage.base' );
Can anyone help me figure out how to do this the right way?
Thanks,
James
[1] https://github.com/desandro/masonry
Hi,
We're coming up on the month of May, which means we'll be working on a 1.29
release! As
the initial step, I'd like to create a branch for REL1_29 this week barring
any major objections.
I'm thinking Thursday evening after we've finished this week's train.
Then we'll be in the normal patch master + backport process we all know and
love until we
do the release (looking at May 25th).
-Chad
= TL;DR
- The codfw deployment server is now Naos: naos.codfw.wmnet [1]. Its
SSH fingerprints are available at [2].
- Mira is no longer a deployment server.
- Naos is also the current active deployment server until May 3rd [3], [4].
- As always, please use the DNS record deployment.eqiad.wmnet to know
which deployment server is the active one.
= Detailed version:
Few days before the datacenter switchover to codfw performed last week
[3], [4], with perfect timing, the existing codfw deployment server
Mira manifested hardware issues.
Being Mira an old server, also out of warranty, a new deployment
server in the codfw datacenter was deployed and configured.
As a result, from now on, the deployment server for the codfw
datacenter is Naos: naos.codfw.wmnet [1]. You can find its SSH
fingerprints in [2].
As part of the datacenter switchover procedures [4], also the
deployment server was switched to codfw, hence Naos is currently the
active deployment server, until the switchback to eqiad as master
datacenter, scheduled on May 3rd [3], [4].
The DNS entries for both deployment.eqiad.wmnet and
deployment.codfw.wmnet always point to the active deployment server
and should be used to verify which one is the active one.
As always, a large message of the day (MOTD) is shown to alert people
to not use the passive deployment server on login, and it is now shown
on both Tin and Mira.
I've also updated all the references to Mira that I've found on
Wikitech, but please verify if you have any direct reference to it
that might need to be updated.
Thanks,
Riccardo
[1] https://wikitech.wikimedia.org/wiki/Naos
[2] https://wikitech.wikimedia.org/wiki/Help:SSH_Fingerprints/naos.codfw.wmnet
[3] https://blog.wikimedia.org/2017/04/18/codfw-temporary-editing-pause/
[4] https://wikitech.wikimedia.org/wiki/Switch_Datacenter
--
Riccardo Coccioli
Software Engineer, Technical Operations
Wikimedia Foundation