Cross-posted to
<http://techblog.wikimedia.org/2010/07/mediawiki-version-statistics/>
Some kind people at Qualys have surveyed versions of open source web
apps present on the web, including MediaWiki. Here is the relevant
page from their presentation:
http://wimg.co.uk/3jK.png
For the original see:
https://community.qualys.com/docs/DOC-1401
And the press release:
<http://www.qualys.com/company/newsroom/newsreleases/usa/view/2010-07-28/>
They make the point that 95% of MediaWiki installations have a
"serious vulnerability", whereas only 4% of WordPress installations
do. While WordPress's web-based upgrade utility certainly has a
positive impact on security, I feel I should point out that what
WordPress counts as a serious vulnerability does not align with
MediaWiki's definition of the same term.
For instance, if a web-based user could execute arbitrary PHP code on
the server, compromising all data and user accounts, we would count
that as the most serious sort of vulnerability, and we would do an
immediate release to fix it. We're proud of the fact that we haven't
had any such vulnerability in a stable release since 1.5.3 (December
2005).
However in WordPress, they count this as a feature, and all
administrators can do it. Similarly, WordPress avoids the difficult
problem of sanitising HTML and CSS while preserving a rich feature set
by simply allowing all authors to post raw HTML.
If you are running MediaWiki in a CMS-like mode, with whitelist edit
and account creation restricted, then I think it's fair to say that in
terms of security, you're better off with MediaWiki 1.14.1 or later
than you are with the latest version of WordPress.
However, the statistics presented by Qualys show that an alarming
number of people are running versions of MediaWiki older than 1.14.1,
which was the most recent fix for an XSS vulnerability exploitable
without special privileges. There is certainly room for us to do better.
We have a new installer project in development, which we hope to
release in 1.17. It includes a feature which encourages users to sign
up for our release announcements mailing list. But maybe we need to do
more. Should we take a leaf from WordPress's book, and nag
administrators with a prominent notice when they are not using the
latest version? Such a feature would require MediaWiki to "dial home",
which is controversial in our developer community.
-- Tim Starling
Here's the basic information about my install:
MediaWiki 1.12.0
PHP 5
Database MySQL
What I'm looking to do is to allow any user with edit permissions to be
able to Protect a page so that only Sysops are able to edit / unprotect
it. To do this I turned on the Protect tab with the following code in
the LocalSettings.php file:
# Only allow users and sysops to protect a page
$wgGroupPermissions['*']['protect'] = false;
$wgGroupPermissions['user']['protect'] = true;
$wgGroupPermissions['sysop']['protect'] = true;
The Protect tab does show up now, and you can protect a page, but when
ANYONE with edit privileges goes to edit they are able to do so
regardless of unprotecting the page or being a sysop. When editing, it
does show the following message, but lets you edit and save anyways:
WARNING: This page has been locked so that only users with sysop
privileges can edit it.
Any thoughts?
Can someone please point me to any reading about this subject? So far I
haven't found anything that explains how to do it. I tried the obvious,
from my user account preferences, but when I gave my openid account name I
was told that it belonged to someone else - so obviously this is not the way
to do it :-)
Anne
--
KDE Community Working Group
New to KDE Software? -
get help from http://userbase.kde.org
I'm a bit confused when I try to match the update instructions for
v1.15.4 with the instructions that I followed for installing v1.14.0 and
wondered if someone might be able to help.
1) my installation instructions said to place v1.14.0 in a version- related
directory so it's in /var/www/mediawiki/mediawiki-1.14.0. The upgrade
instructions say to write v1.15.4 files over these but it would be confusing
to have v1.15.4 files in a v1.14.0 directory so I've currently placed them
in /var/www/mediawiki/mediawiki-1.15.4. But I'm guessing that I will need to
tell parts of mediawiki/apache2/php that mediawiki will be in a new
location. Where are these references to the mediawiki folder please? Or do I
not need to worry about this because the update proces will take account of
it all? (I thought I'd edited the mediawiki folder name into an apache alias
at one point for example rather than the installation scrtipt doing
everything for me).
2) the update instructions say I might not have an AdminSettings.php file
but later say I must have one and it's used in the update.php command line.
I don't have one for my v1.14.0 mediawiki so do I need this and if not what
is the command for running update without it please?
Thanks for any pointers you might have.
Kevin
Excerpts from Platonides's message of Sun Aug 01 17:39:19 -0400 2010:
> I'm not sure that's comparable. If WordPress complains for being an old
> version, unsavy users will want it to be upgraded for them. Whereas if
> they watched the relevant mailing list they probably have the required
> skills to manually update.
> (Since they chose a 'managed' mediawiki, it's not that they would be
> required to do it anyway)
Right, so it's an interesting combination of factors.
* Does the application tell the user that their version is out of date?
* Does the application let an unsavvy user upgrade the application with
a single click?
Our experience suggests that if the answers to these questions are yes,
unsavvy users will definitely exercise the feature.
> Does that mean that they chose that version despite being outdated?
> I wonder if all those 1.5.8 installs are due to thinking 1.5 is greater
> than 1.15
No, that just means they installed 1.5.8 back when it was still the default,
and then we didn't manage to upgrade them.
> There's probably some interesting knowledge on looking how they patched
> it, but I don't know how to easily extract it.
A good starting point would probablyb e "most edited files".
Cheers,
Edward
Hi,
I am trying to write the simplest extension using a parser function
(to get the feel of it). My extension is supposed to greet anyone who
uses it. I am using this wikipage (
http://www.mediawiki.org/wiki/Manual:Parser_functions) as the
reference
However, I am unable to get even this simplest extension to work. Can
anyone help me fix this. I am quite lost.
Any help will be greatly appreciated.
Thanks,
Alok
This is what I have in my LocalSettings.php
#################### Say Hello Extensions ############################
require_once( "$IP/extensions/sayHello.php");
#################### End of exension ################################
And here is the file $IP/extensions/sayHello.php
<?php
// Is this the right entry point ?
if ( !defined( 'MEDIAWIKI' ) )
{
die( 'Not an entry point.' );
}
global $wgExtensionFunctions; // I dont know if this is needed. I
could not find a clear description about it.
global $wgExtensionCredits; // Same as above.... I am doing this
out of desperation to make this work
$wgExtensionFunctions[] = 'wfSayHello'
$wgExtensionCredits['SayHello'][] = array(
'name' => 'SayHello',
'author' => 'Alok',
'url' => '',
'description' => 'Extension that greets user',
'descriptionmsg' => 'This is a test extension',
'version' => '1.0.0',
);
global $wgHooks
$wgHooks['SayHello'][] = "wfSayHello";
global $wgParser;
$wgParser->setFunctionHook('SayHello', 'wfSayHello');
function wfSayHello($parser, $userNameInput)
{
return "Hello " . $userNameInput;
}
return true;
?>
