Following change I189ba71de[0], the hierarchical list in
Special:Allpages becomes a simple alphabetic pager if the total number
of pages exceeds a safety threshold. The threshold is designed to
protect wikis on which the load generated by the process of generating
the hierarchical list would be prohibitively expensive (bug 56840[1]).
I189ba71de resolved the immediate operational issue, but there is a
further question of whether we want to keep the hierarchical list at
all, especially given that it cannot be enabled (in its current
implementation, at least) on larger installations.
>From my perspective, the ideal outcome of this discussion would be
that we agree that the hierarchical list is a poor fit for the
MediaWiki of today, and we resolve to remove it from core.
According to stats.grok.se, enwiki's Special:Allpages receives
approximately 158 hits a day.[2]
[0]: https://gerrit.wikimedia.org/r/#/c/94690/
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=56840
[2]: http://stats.grok.se/en/latest90/Special:Allpages
---
Ori Livneh
ori(a)wikimedia.org
I'm happy to announce the availability of the second beta release of the
new MediaWiki 1.19 release series.
Please try it out and let us know what you think. Don't run it on any
wikis that you really care about, unless you are both very brave and
very confident in your MediaWiki administration skills.
MediaWiki 1.19 is a large release that contains many new features and
bug fixes. This is a summary of the major changes of interest to users.
You can consult the RELEASE-NOTES-1.19 file for the full list of changes
in this version.
Five security issues were discovered.
It was discovered that the api had a cross-site request forgery (CSRF)
vulnerability in the block/unblock modules. It was possible for a user
account with the block privileges to block or unblock another user without
providing a token.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212
It was discovered that the resource loader can leak certain kinds of private
data across domain origin boundaries, by providing the data as an executable
JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of
CSRF
protection tokens. This allows compromise of the wiki's user accounts, say
by
changing the user's email address and then requesting a password reset.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907
Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF)
vulnerability in Special:Upload. Modern browsers (since at least as early as
December 2010) are able to post file uploads without user interaction,
violating previous security assumptions within MediaWiki.
Depending on the wiki's configuration, this vulnerability could lead to
further
compromise, especially on private wikis where the set of allowed file types
is
broader than on public wikis. Note that CSRF allows compromise of a wiki
from
an external website even if the wiki is behind a firewall.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317
George Argyros and Aggelos Kiayias reported that the method used to generate
password reset tokens is not sufficiently secure. Instead we use various
more
secure random number generators, depending on what is available on the
platform. Windows users are strongly advised to install either the openssl
extension or the mcrypt extension for PHP so that MediaWiki can take
advantage
of the cryptographic random number facility provided by Windows.
Any extension developers using mt_rand() to generate random numbers in
contexts
where security is required are encouraged to instead make use of the
MWCryptRand class introduced with this release.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078
A long-standing bug in the wikitext parser (bug 22555) was discovered to
have
security implications. In the presence of the popular CharInsert extension,
it
leads to cross-site scripting (XSS). XSS may be possible with other
extensions
or perhaps even the MediaWiki core alone, although this is not confirmed at
this time. A denial-of-service attack (infinite loop) is also possible
regardless of configuration.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315
*********************************************************************
What's new?
*********************************************************************
MediaWiki 1.19 brings the usual host of various bugfixes and new features.
Comprehensive list of what's new is in the release notes.
* Bumped MySQL version requirement to 5.0.2.
* Disable the partial HTML and MathML rendering options for Math,
and render as PNG by default.
* MathML mode was so incomplete most people thought it simply didn't work.
* New skins/common/*.css files usable by skins instead of having to copy
piles of
generic styles from MonoBook or Vector's css.
* The default user signature now contains a talk link in addition to the
user link.
* Searching blocked usernames in block log is now clearer.
* Better timezone recognition in user preferences.
* Extensions can now participate in the extraction of titles from URL paths.
* The command-line installer supports various RDBMSes better.
* The interwiki links table can now be accessed also when the interwiki
cache
is used (used in the API and the Interwiki extension).
Internationalization
- --------------------
* More gender support (for instance in user lists).
* Add languages: Canadian English.
* Language converter improved, e.g. it now works depending on the page
content language.
* Time and number-formatting magic words also now depend on the page
content language.
* Bidirectional support further improved after 1.18.
Release notes
- -------------
Full release notes:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE
LEASE-NOTES-1.19;hb=1.19.0beta2
https://www.mediawiki.org/wiki/Release_notes/1.19
Co-inciding with these security releases, the MediaWiki source code
repository has
moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3)
to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the
relevant
commits for these releases will not be appearing in our SVN repository. If
you use
SVN checkouts of MediaWiki for version control, you need to migrate these to
Git.
If you up are using tarballs, there should be no change in the process for
you.
Please note that any WMF-deployed extensions have also been migrated to Git
also, along with some other non WMF-maintained ones.
Please bear with us, some of the Git related links for this release may not
work instantly,
but should later on.
To do a simple Git clone, the command is:
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git
More information is available at https://www.mediawiki.org/wiki/Git
For more help, please visit the #mediawiki IRC channel on freenode.netirc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list
at mediawiki-l(a)lists.wikimedia.org.
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz
Patch to previous version (1.19.0beta1), without interface text:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc
h.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.si
g
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz.
sig
http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc
h.gz.sig
Public keys:
https://secure.wikimedia.org/keys.html
Hi,
Just like every first Tuesday of the month [1], the Engineering
Community team has reviewed and fine tuned the monthly and quarterly plans:
https://www.mediawiki.org/wiki/Engineering_Community_Team/Meetings
With Google Code-in and Outreach Program for Women starting soon, this
month is expected to be very busy.
We also have our team's quarterly review, which we expect will be useful
to sync our longer term plans with our actual activities - see
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals#Wikimedi…
Last week we had the monthly ECT Showcase, just like every last Tuesday
of the month [1]. There we presented a selection of tasks completed in
October. You can watch the video at
http://www.youtube.com/watch?v=Y3Gl-oR2ucU (copy to Commons pending,
help welcome).
Next week we will have our monthly IRC meeting, just like every second
Tuesday of the month. You can propose topics to be discussed at
https://www.mediawiki.org/wiki/Engineering_Community_Team/Meetings#2013-11-…
That is all for now. We will use this thread for future updates.
Questions? Just ask.
[1] Just joking, we only completed a first iteration.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
I have just pushed a new version of the TitleValue patch to Gerrit:
<https://gerrit.wikimedia.org/r/106517>.
I have also updated the RDF to reflect the latest changes:
<https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue>.
Please have a look. I have tried to address several issues with the previous
proposal, and reduce the complexity of the proposal. I have also tried to adjust
the service interfaces to make migration easier.
Any feedback would be very welcome!
-- daniel
The structured logging RFC [0] will be up for discussion again next
Wednesday [1]. There is a strawman implementation in gerrit [2] that
is likely to be the focus of discussion unless there are other issues
that the reviewers find more pressing.
At this point the most controversial aspect of my proposed
implementation seems to be importing third-party libraries into
mw-core and/or the use of composer to manage that activity. I would
welcome discussion of alternatives or consensus that this is a
reasonable approach for the immediate future that should be revisited
if and when a better idea is found for the general problem.
[0]: https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging
[1]: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-19
[2]: https://gerrit.wikimedia.org/r/#/c/112699/
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
The application deadline for GSoC and FOSS OPW has passed. The pool of
candidates to choose from includes
* 43 GSoC proposals from 42 candidates
* 18 OPW proposals from 18 candidates, one of them a GSoC candidate as well
There are many projects that have received several proposals. In a few
hours the dust will settle in the wiki pages, where many candidates are
currently syncing their information.
https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_8
Everybody is invited to join the selection process.
https://www.mediawiki.org/wiki/Mentorship_programs/Selection_process
All mentors must join the GSoC or OPW review websites in order to join the
private evaluation of candidates. The rest of the community is encouraged
to help reviewing proposals and asking hard questions to candidates and
mentors in their respective talk pages or Bugzilla reports.
By April 7 we need to decide how many slots we want to request in each
program. In GSoC we request a number of slots to Google, which we might or
might not get. In OPW we fund some slots, we might request more, and then
we might get them or not.
Questions? Just ask.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
On Wed, Mar 26, 2014 at 9:56 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> I agree Max, that would be a great patch to get finish.
>
> Pulling in wikitech for wider discussion since it seems Timo wanted a
> wider discussion.
>
> tldr: Let's add a method of template/blob delivery into ResourceLoader
> from server->client which is agnostic of which template library is
> being used and allows Flow and MobileFrontend to share code rather
> than running their own identical systems in 2 separate extensions.
>
>
> On Tue, Mar 25, 2014 at 6:01 PM, Max Semenik <maxsem.wiki(a)gmail.com> wrote:
>> On 26.03.2014, 3:37 Jon wrote:
>>
>>> Gabriel's work is on a standard templating choice for all projects.
>>> ResourceLoader support will inevitably be needed for that too. We
>>> believe that upstreaming this code and making it agnostic to the
>>> template language (which it will have to be if Flow is using
>>> Handlebars in the meantime) will lead to a good generic piece of code
>>> that Knockoff can be easily plugged into in future.
>>
>> I already experimented in this area: https://gerrit.wikimedia.org/r/111250
>> would be great if we finished this...
>>
>> --
>> Best regards,
>> Max Semenik ([[User:MaxSem]])
>>
Hey,
Regarding
https://github.com/wikimedia/mediawiki-core/blob/793f17481ea937275898c91b9b…
So now all extensions that want to retain compatibility with MediaWiki 1.22
and at the same time not have deprecation notices on 1.23 need to do an
if-else for all calls to this method? That sucks big time. And for what?
The old method is just forwarding to the new one. All this hassle for a
rename? How about removing the wfDeprecated call and not annoying all
extension maintainers?
Cheers
--
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Evil software architect at Wikimedia Germany
~=[,,_,,]:3
I've been bothered for awhile by the mess we have in resources/jquery/ –
3rd party libraries, custom libraries we have to maintain, and directly
MW related code using mediaWiki.* APIs all mixed together in the same
directory. So I went and audited the .js we have inside
resources/jquery/ and have wrote up an RFC on it:
https://www.mediawiki.org/wiki/Requests_for_comment/Isolate_custom_jQuery_l…
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]