Hi!
Soooo, it's that wonderful time of year where we start prepping for a new
general release
of MediaWiki! This one will be 1.28.0, and it'll be based on all of the
1.28 wmf branches we've
been doing over the past 6 months.
Step 1 is cutting the branch, which I plan to do tomorrow from the same
branch point which we
cut the 1.28.0-wmf.23. This is slightly different, in that we won't be
cutting from master a few days
after the WMF branch, and takes some of the pressure off of creating
1.29.0-wmf.1 the following
week.
So here's the timeline:
Tomorrow (Oct 25) - Cut REL1_28 from wmf.23, master goes to 1.29-alpha
Tues (Nov 1) - First deployment of 1.29 to WMF [wmf.1, obviously]
Wednesday (Nov 2) - Do rc.0 [giving us a few days for any backports that
came up in wmf.23 rollout]
Following two Wednesdays (Nov 9, 16) - Do rc.1 and rc.2
Wednesday (Nov 23) - Final release of MW
I'll be updating MW.org shortly.
Tyler Cipriani's assisting me with this release, so expect to see some RCs
with his name
(and signatures) on them :)
-Chad
The parsing team has fixed a security bug in Parsoid [1].
* Users could send invalid prefixes, formats, or domains and run
javascript code on the error page that Parsoid displayed.
* This fix has been applied to the Wikimedia cluster [2] and also merged
into Parsoid master [1].
* We have also released a 0.5.3 deb version with this patch applied. [3]
* We have also released a 0.5.3 npm version of Parsoid. [4]
* Parsoid is a stateless service and doesn't retain any state between
requests. In private wikis, VisualEditor can be configured to
forward the user cookie to Parsoid to pass along to the MediaWiki API
to parse a page, but this exploit is not exposed through VE.
In addition, Parsoid doesn't receive any user credentials on
public wikis.
* However, if a wiki's Parsoid service is publicly accessible on the
internet *and* is accessible through the wiki's domain, then, this
exploit can be used to leak user cookies for that wiki. For all wikis
that use Parsoid in this fashion, we recommend they patch their
Parsoid installation immediately.
* On the Wikimedia cluster, Parsoid is proxied behind RESTBase and is
not public accessible and as such, this exploit wasn't available for
an exploit to steal user sessions.
Thanks to the reporter of this exploit, Darian Patrick from the
Security Team, Arlo Breault from the Parsing Team, Daniel Zahn and
others from Ops for their assistance handling this bug and preparing
this release.
Subramanya Sastry,
Technical Lead and Manager,
Parsing Team,
Wikimedia Foundation.
[1] https://gerrit.wikimedia.org/r/#/c/319115
[2]
https://www.mediawiki.org/wiki/Parsoid/Deployments#Monday.2C_October_31.2C_…
[3] https://releases.wikimedia.org/debian/pool/main/p/parsoid/
[4] https://www.npmjs.com/package/parsoid
_______________________________________________
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
The parsing team has fixed a security bug in Parsoid [1].
* Users could send invalid prefixes, formats, or domains and run
javascript code on the error page that Parsoid displayed.
* This fix has been applied to the Wikimedia cluster [2] and also merged
into Parsoid master [1].
* We have also released a 0.5.3 deb version with this patch applied. [3]
* We have also released a 0.5.3 npm version of Parsoid. [4]
* Parsoid is a stateless service and doesn't retain any state between
requests. In private wikis, VisualEditor can be configured to
forward the user cookie to Parsoid to pass along to the MediaWiki API
to parse a page, but this exploit is not exposed through VE.
In addition, Parsoid doesn't receive any user credentials on public
wikis.
* However, if a wiki's Parsoid service is publicly accessible on the
internet
*and* is accessible through the wiki's domain, then, this exploit can be
used to leak user cookies for that wiki. For all wikis that use Parsoid
in this fashion, we recommend they patch their Parsoid installation
immediately.
* On the Wikimedia cluster, Parsoid is proxied behind RESTBase and is
not public accessible and as such, this exploit wasn't available for
an exploit to steal user sessions.
Thanks to the reporter of this exploit, Darian Patrick from the Security
Team,
Arlo Breault from the Parsing Team, Daniel Zahn and others from Ops for
their
assistance handling this bug and preparing this release.
[1] https://gerrit.wikimedia.org/r/#/c/319115
[2]
https://www.mediawiki.org/wiki/Parsoid/Deployments#Monday.2C_October_31.2C_…
[3] https://releases.wikimedia.org/debian/pool/main/p/parsoid/
[4] https://www.npmjs.com/package/parsoid
Subramanya Sastry,
Technical Lead and Manager,
Parsing Team,
Wikimedia Foundation.
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2016-10): 296
Active users (any activity) in (2016-10): 870
Task authors in (2016-10): 471
Users who have closed tasks in (2016-10): 254
Projects which had at least one task moved from one column to another on
their workboard in (2016-10): 263
Tasks created in (2016-10): 2543
Tasks closed in (2016-10): 2107
Open and stalled tasks in total: 32164
Median age in days of open tasks by priority:
Unbreak now: 30
Needs Triage: 213
High: 384
Normal: 530
Low: 823
Lowest: 698
(How long tasks have been open, not how long they have had that priority)
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on iridium at Tue Nov 1 00:00:15 UTC 2016)