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-
i'm hopeful this is the appropriate venue for this topic - i recently
had occasion to visit #mediawiki on freenode, looking for help. i found
myself a bit frustrated by the amount of bot activity there and wondered
if there might be value in some consideration for this. it seems to
frequently drown out/dilute those asking for help, which can be a bit
discouraging/frustrating. additionally, from the perspective of those
who might help [based on my experience in this role in other channels],
constant activity can sometimes engender disinterest [e.g. the irc
client shows activity in the channel, but i'm less inclined to look as
it's probably just a bot].
to offer one possibility - i know there are a number of mediawiki and/or
wikimedia related channels - might there be one in which bot activity
might be better suited, in the context of less contention between the
two audiences [those seeking help vs. those interested in development,
etc]? one nomenclature convention that seems to be at least somewhat of
a defacto standard is #project for general help, and #project-dev[el]
for development topics. a few examples of this i've seen are android,
libreoffice, python, and asterisk. adding yet another channel to this
list might not be terribly welcome, but maybe the distinction would be
worth the addition?
as i'm writing this, i see another thread has begun wrt freenode, and i
also see a bug filed that relates at least to some degree
[https://bugzilla.wikimedia.org/show_bug.cgi?id=35427], so i may just be
repeating an existing sentiment, but i wanted to at least offer a brief
perspective.
regards
-ben
On Fri, Jun 15, 2012 at 8:48 AM, Sumana Harihareswara
<sumanah(a)wikimedia.org> wrote:
> If you merge into mediawiki/core.git, your change is considered safe for
> inclusion in a wmf branch. The wmf branch is just branched out of
> master and then deployed. We don't review it again. Because we're
> deploying more frequently to WMF sites, the code review for merging into
> MediaWiki's core.git needs to be more like deployment/shell-level
> review, and so we gave merge access to people who already had deployment
> access. We have since added some more people. The current list:
> https://gerrit.wikimedia.org/r/#/admin/groups/11,members
Let me elaborate on this. As unclear as our process is for giving
access, it's even less clear what our policy is for taking it away.
If we can settle on a policy for taking access away/suspending access,
it'll make it much easier to loosen up about giving access.
Here's the situation we want to avoid: we give access to someone who
probably shouldn't have it. They continually introduce deployment
blockers into the code, making us need to slow down our frequent
deployment process. Two hour deploy windows become six hour deploy
windows as we need time to fix up breakage introduced during the
window. Even with the group we have, there are times where things
that really shouldn't slip through do. It's manageable now, but
adding more people is going to multiply this problem as we get back
into a situation where poorly conceived changes become core
dependencies.
We haven't had a culture of making a big deal about the case when
someone introduces a breaking change or does something that brings the
db to its knees or introduces a massive security hole or whatever.
That means that if the situation were to arise that we needed to
revoke someones access, we have to wait until it gets egregious and
awful, and even then the person is likely to be shocked that their
rights are being revoked (if we even do it then). To be less
conservative about giving access, we also need to figure out how to be
less conservative about taking it away. We also want to be as
reasonably objective about it. It's always going to be somewhat
subjective, and we don't want to completely eliminate the role of
common sense.
It would also be nice if we didn't have to resort to the nuclear
option to get the point across. One low-stakes way we can use to make
sure people are more careful is to have some sort of rotating "oops"
award. At one former job I had, we had a Ghostbusters Stay Puft doll
named "Buster" that was handed out when someone broke the build that
they had to prominently display in their office. At another job, it
was a pair of Shrek ears that people had to wear when they messed
something up in production. In both cases, it was something you had
to wear until someone else came along. Perhaps we should institute
something similar (maybe as simple as asking people to append "OOPS"
to their IRC nicks when they botch something).
Rob
Hi everybody,
at last weekend's Hackathon I investigated how to get into bug
management/triaging in Wikimedia.
I'd like to propose some changes in order to streamline, harmonize and
centralize documentation in order to make it easier to get involved:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Improv…
Feedback, comments, criticism on this draft are very welcome.
andre
--
Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
http://blogs.gnome.org/aklapper/
Hey,
Is it possible to push to a branch other then the default one on gerrit
using git review?
This is needed when you want to have more then one branch on which you have
reviewed code, or if you want different levels of review. For example if
you want a novice committer play around with an extension a bit and push
new functionality that gets reviewed but is not ready to go onto master
until it really has stabilized and finalized.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
> Message: 8
> Date: Wed, 23 May 2012 21:49:57 +0200
> From: Platonides <Platonides(a)gmail.com>
> To: wikitech-l(a)lists.wikimedia.org
> Subject: Re: [Wikitech-l] HTMLMultiSelectField as <select
> multiple="multiple"/>
> Message-ID: <jpjf1s$b23$1(a)dough.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 23/05/12 19:16, Daniel Werner wrote:
> > Right now I am implementing a new option (as part of
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd
like to
> > use a <select multiple="multiple"/> html element with options. Right now
> > MediaWiki always generates a list of selectboxes instead of that when
using
> > the HTMLMultiSelectField class. We are talking about 280+ selectable
items
> > here, so for now we came to the conclusion that a real multi <select/>
> > would be nicer and less space consuming for now
> > I have already managed to implement this multiple select,
> > modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which
> > can be set to false to disable the known behavior and use a select
element
> > instead.
> >
> > This would mainly be for the JavaScript-less ui. If javascript were
> > enabled, we could still do something nicer, for example with something
like
> > jQuery chosen plugin here.
> >
> > My question would just be, how I should implement these changes
preferably.
> > Is it ok with the new option for HTMLMultiSelectField or should this be
a
> > new class inheriting from HTMLMultiSelectField? I think
> > HTMLMultiSelectField sounds more like describing what I just implemented
> > rather than a bunch of select boxes, but of course renaming the existing
> > one could "break" extensions (even though both are fully compatible and
> > interchangeable). So one option would be simply naming the new one
> > HTMLMultiSelectField2 if we don't want to stick with an additional
option
> > here.
>
> No. You shouldn't need to know that HTMLMultiSelectField2 is a
> MultiSelect but HTMLMultiSelectField uses checkboxes.
> Your useCheckboxes looks good.
> I recommend you to make it a tri-state value, so you could force
> checkboxes, select or let it decide (eg. checkboxes for < 100 elements,
> select for more)
Alright, just submitted this for review to gerrit:
https://gerrit.wikimedia.org/r/#/c/8924/
I implemented it as tri-state now. By default 'usecheckboxes' will be true,
not set to a number. This could be changed (would make sense imo) but for
now I didn't want to do this since it could for example affect the default
search namespace user preference in wikis with many search namespaces. I
think the plain multiple select HTML element is not that nice because it is
not very obvious that you can do multiple selects by holding the control
key. There should be some JavaScript ui element replacing this for users
having JS enabled I think before using this as default for huge multiselect
options. I think if all of that were implemented, 15 or 20 would be a good
default value for the option.
Cheers
Daniel
Hi,
Sorry about the length of this mail, it reads faster than it looks.
I am working with the recentchanges and the cu_changes (checkuser)
mediawiki SQL tables. I would like to be able to filter bot activity,
unfortunately I am increasingly confused.
Things that I think I know:
- In the recentchanges<http://www.mediawiki.org/wiki/Manual:Recentchanges_table>
table
there is a `rc_bot` flag that should indicate whether the edit comes from a
bot.
- The checkuser table
cu_changes<http://www.mediawiki.org/wiki/Extension:CheckUser> (which
is not documented on the mediawiki database layout
page<http://www.mediawiki.org/wiki/Manual:Database_layout>)
contains mostly the same information as the recentchanges table but for a
longer period of time. However, there is no bot flag as there is on the
recentchanges table - I don't know why not.
- There is a `bot` entry in the
user_groups.ug_group<http://www.mediawiki.org/wiki/Manual:User_groups_table>
field.
A revision/recentchanges/cu_changes entry can be identified as bot by
joining the original table with user_groups on the user_id and by setting
ug_group=`bot`.
- The user_groups method way of identifying bots is inefficient and the
data seems incomplete. For some other projects we have used various other
bot tables created by hand (on db1047: halfak.bot used during WSOR 2011 or
declerambaul.erik_bots containing the bots identified by Erik Zachte).
I would like to know the answers to the following questions:
1. *What is the meaning/purpose of the rc_bot flag on recentchanges? *There
are entries in the recentchanges table from editors that are flagged as
bots in the user_groups and the other bot tables but still have the rc_bot
flag set to 0.
mysql> select rc.rc_user_text from recentchanges rc join user_groups ug ON
(rc.rc_user=ug.ug_user) WHERE ug.ug_group = 'bot' and rc.rc_bot=0 limit 1;
+--------------+
| rc_user_text |
+--------------+
| ClueBot NG |
+--------------+
2. *Why is there no bot flag in the checkuser table? *A lot of the other
fields seem to be copied from the recentchanges table, why not the rc_bot
field? The check user table contains both entries that are flagged as bots
in the recentchanges table and entries that are flagged as bots in the
user_groups.
mysql> select cuc.cuc_user_text from recentchanges rc join cu_changes cuc
ON (rc.rc_user=cuc.cuc_user) WHERE rc.rc_bot=1 limit 1;
+---------------+
| cuc_user_text |
+---------------+
| MiszaBot III |
+---------------+
mysql> select cuc.cuc_user_text from cu_changes cuc join user_groups ug ON
(cuc.cuc_user=ug.ug_user) WHERE ug.ug_group = 'bot' limit 1;
+---------------+
| cuc_user_text |
+---------------+
| Robbot |
+---------------+
3. *Am I missing some fundamental information about how bots are handled?* This
is a frequently recurring request for data analytics and it seems the data
is inconsistent.
What is the most convenient, sane way to classify bot activity as such? Are
there any projects underway that aim to improve the situation? Any input,
pointers and recommendations are much appreciated.
Thanks a lot! Regards,
Fabian
Since MediaWiki 1.18 we have the variable $wgUseCombinedLoginLink [1]
which is set to true per default.
During edit workshops with students and seniors I registered that new
editors are confused about the combined login page. They tried to
register new accounts on the login page.
Surely, these observations are not representative but I think that the
usability could be improved by setting $wgUseCombinedLoginLink=false
If I missed a prior discussion about this issue I apologize and would be
happy if someone could point me to the discussion.
Otherwise I suggest to set $wgUseCombinedLoginLink to false for all WMF
wikis.
Raimond.
[1] https://www.mediawiki.org/wiki/Manual:$wgUseCombinedLoginLink
Hey all,
Now that we're on a more regular deployment schedule, staying on top of the
blocking bugs and deviding lists into smaller, more managable chunks, is more
and more important.
For that reason I put together a quick tool:
https://toolserver.org/~krinkle/wmfBugZillaPortal/
It is already becoming clear that there is a lot of stuff left behind from past
versions. We should probably start moving stuff to later verisons and keep an
eye on it more regularly.
-- Krinkle
Hey,
I am looking into generalizing how interwiki and interlanguage links are
stored. The motivation for this is because what's currently there does not
allow holding the information needed to have Wikidata work. Before I
continue work on this (ie figuring out how to best modify core code to not
break existing features and tools) I'd like some feedback on the schema
changes I'm thinking of making.
They are described here:
https://www.mediawiki.org/wiki/User:Jeroen_De_Dauw/Wikibase_sites_and_site_…
Some important changes to interwiki/sites compared to the current setup:
* Allows having "interlanguage links" that are not "interwiki links"
* Allows automatic synchronizing of site definitions between between all
clients (ie all Wikipedias).
* Site definitions can exist that are not used as "interlanguage link" and
not used as "interwiki link"
* Allows distinguishing between local and global identifiers
* Maps between global and local identifiers
* Holds information on the type of site. This way code can know that
bugzilla does not have a MW api.php :)
The change to the langlinks table is needed to distinguish between links
that are defined in local articles and links pulled from an external source
so that the code rebuilding links for an article knows to ditch the local
notes not in the article but keep the external ones. This is a table with
lots of rows. Anyone an estimate on how long it would take to add a boolean
field with initial value true?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--