MediaWiki version statistics

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

MediaWiki version statistics

Tim Starling-2
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Ryan Lane-2
> 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.
>

If MediaWiki dials home, it should be configurable in such a way that
it can be turned off. There are instances in use in places that would
prefer not to their presence known. Enterprise use in general fits
this category.

Respectfully,

Ryan Lane

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Jeroen De Dauw-2
In reply to this post by Tim Starling-2
Hey,

As many of you probably already know, my Google Summer of Code project [0]
aims at providing this exact "dial home" functionality, for both MediaWiki
core and extensions. (The project's goal is wider than this, but this is
included as one of the main features.)

> If MediaWiki dials home, it should be configurable in such a way that it
can be turned off. There are instances in use in places that would prefer
not to their presence known. Enterprise use in general fits this category.

I totally agree here with Ryan. The idea is to have the "repository" where
the version data is fetched is configurable, so it's possible to have other
distributors then the WMF, and to turn of the feature entirely.

I'm currently looking into the repository and package fetching parts do
allow for such "dialling home". MediaWiki.org seems the obvious choice to
have the main repository on. There are many ways to then provide the needed
data. Personally I think the best approach would be to install Semantic
MediaWiki (yes, I used the s-word!) so data from the extension pages can be
queried and shown in a distribution metadata format. That might require a
small extension for some new spacial pages, and some scripts to collect
other existing version data and put it into the wiki.

Is it possible to get SMW onto MW.org? This would also finally be a proof of
concept of SMW on a WMF wiki, on which a lot of people have been waiting a
long time now.

With only a little over 3 weeks left in GSoC, I have little doubt this
project will not be finished, so any help in any form is definitely welcome.


[0] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Deployment

Cheers

--
Jeroen De Dauw
* http://blog.bn2vs.com
* http://wiki.bn2vs.com
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69
66 65!
--


On 30 July 2010 06:35, Tim Starling <[hidden email]> wrote:

> 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
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Max Semenik
On 30.07.2010, 17:44 Jeroen wrote:


> I'm currently looking into the repository and package fetching parts do
> allow for such "dialling home". MediaWiki.org seems the obvious choice to
> have the main repository on. There are many ways to then provide the needed
> data. Personally I think the best approach would be to install Semantic
> MediaWiki (yes, I used the s-word!) so data from the extension pages can be
> queried and shown in a distribution metadata format. That might require a
> small extension for some new spacial pages, and some scripts to collect
> other existing version data and put it into the wiki.

There's already http://www.mediawiki.org/wiki/Extension:MWReleases that does
server part of version checks for core, it could be tweaked to
supply version information for extensions, too.


> Is it possible to get SMW onto MW.org? This would also finally be a proof of
> concept of SMW on a WMF wiki, on which a lot of people have been waiting a
> long time now.

Last time I heard about it, it had huge problems with security and
code quality. Did anything change positively in that area over the
last several months? If s***c developers believe that all Tim's
concerns have been addressed, they should resubmit it for review.

--
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Max Semenik
On 30.07.2010, 18:20 /me wrote:

> There's already http://www.mediawiki.org/wiki/Extension:MWReleases that does
> server part of version checks for core

And we forgot to update it when 1.16 was released, wheee! Added to
release checklist now.


--
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Jeroen De Dauw-2
In reply to this post by Max Semenik
Hey,

> There's already http://www.mediawiki.org/wiki/Extension:MWReleases that
does server part of version checks for core, it could be tweaked to supply
version information for extensions, too.

Although that suffices for determining if your version is up to date or not,
it does not allow for actual update fetching and all the related stuff such
as dependency resolution and simply browsing through available extensions in
the repository, as you have with WordPress.

> When for updates to the software, both core and extensions the system is
to phone home, it makes sense to integrate the LocalisationUpdate
functionality and make it a more complete package.

Yes, that makes a lot of sense. I was not aware this functionality existed,
so I'm definitely going to have a look at it now.

Cheers

--
Jeroen De Dauw
* http://blog.bn2vs.com
* http://wiki.bn2vs.com
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69
66 65!
--


On 30 July 2010 16:20, Max Semenik <[hidden email]> wrote:

> On 30.07.2010, 17:44 Jeroen wrote:
>
>
> > I'm currently looking into the repository and package fetching parts do
> > allow for such "dialling home". MediaWiki.org seems the obvious choice to
> > have the main repository on. There are many ways to then provide the
> needed
> > data. Personally I think the best approach would be to install Semantic
> > MediaWiki (yes, I used the s-word!) so data from the extension pages can
> be
> > queried and shown in a distribution metadata format. That might require a
> > small extension for some new spacial pages, and some scripts to collect
> > other existing version data and put it into the wiki.
>
> There's already http://www.mediawiki.org/wiki/Extension:MWReleases that
> does
> server part of version checks for core, it could be tweaked to
> supply version information for extensions, too.
>
>
> > Is it possible to get SMW onto MW.org? This would also finally be a proof
> of
> > concept of SMW on a WMF wiki, on which a lot of people have been waiting
> a
> > long time now.
>
> Last time I heard about it, it had huge problems with security and
> code quality. Did anything change positively in that area over the
> last several months? If s***c developers believe that all Tim's
> concerns have been addressed, they should resubmit it for review.
>
> --
> Best regards,
>  Max Semenik ([[User:MaxSem]])
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Chad
In reply to this post by Max Semenik
On Fri, Jul 30, 2010 at 7:20 AM, Max Semenik <[hidden email]> wrote:
> There's already http://www.mediawiki.org/wiki/Extension:MWReleases that does
> server part of version checks for core, it could be tweaked to
> supply version information for extensions, too.
>

It's being rewritten, FYI.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Jeroen De Dauw-2
Hey,

Can you provide some more information about that? Rewritten how?

Cheers

--
Jeroen De Dauw
* http://blog.bn2vs.com
* http://wiki.bn2vs.com
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69
66 65!
--


On 30 July 2010 17:20, Chad <[hidden email]> wrote:

> On Fri, Jul 30, 2010 at 7:20 AM, Max Semenik <[hidden email]>
> wrote:
> > There's already http://www.mediawiki.org/wiki/Extension:MWReleases that
> does
> > server part of version checks for core, it could be tweaked to
> > supply version information for extensions, too.
> >
>
> It's being rewritten, FYI.
>
> -Chad
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

MediaWiki version statistics

Max Semenik
In reply to this post by Jeroen De Dauw-2
/me wrote:

> Last time I heard about it, it had huge problems with security and
> code quality. Did anything change positively in that area over the
> last several months? If s***c developers believe that all Tim's
> concerns have been addressed, they should resubmit it for review.

Sorry, as Jeroen noted, only SemanticForms had these problems. My bad.

--
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

K. Peachey
In reply to this post by Jeroen De Dauw-2
On Sat, Jul 31, 2010 at 12:28 AM, Jeroen De Dauw <[hidden email]> wrote:

> Hey,
>
>> There's already http://www.mediawiki.org/wiki/Extension:MWReleases that
> does server part of version checks for core, it could be tweaked to supply
> version information for extensions, too.
>
> Although that suffices for determining if your version is up to date or not,
> it does not allow for actual update fetching and all the related stuff such
> as dependency resolution and simply browsing through available extensions in
> the repository, as you have with WordPress.
>
>> When for updates to the software, both core and extensions the system is
> to phone home, it makes sense to integrate the LocalisationUpdate
> functionality and make it a more complete package.
>
> Yes, that makes a lot of sense. I was not aware this functionality existed,
> so I'm definitely going to have a look at it now.
 I would highly unrecommended having the update feature in there, we
already highly recommend against running as a db user with certain
admins rights amongst other things, this feature will probably end up
breaking more installs then updating (and yes I know wordpress has it,
and I know how many times i've had to fix their botch updates), and
not all installs would have the required modules that it needs
(cURL/wGet comes to mind on IIS setups which some people use). Nor
should we be assigning the update right or giving messages to the
admin group by default, since most people that are admins are non
technical and will just click any bright button that has messages
along the lines of "omg update me now" without thinking if it will
break something (Perhaps we should un-deprecate the developer
usergroup for this).

-Peachey

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

K. Peachey
In reply to this post by Max Semenik
On Sat, Jul 31, 2010 at 1:52 AM, Max Semenik <[hidden email]> wrote:

> /me wrote:
>
>> Last time I heard about it, it had huge problems with security and
>> code quality. Did anything change positively in that area over the
>> last several months? If s***c developers believe that all Tim's
>> concerns have been addressed, they should resubmit it for review.
>
> Sorry, as Jeroen noted, only SemanticForms had these problems. My bad.
>
> --
>  Max Semenik ([[User:MaxSem]])
That was the only one checked wasn't it? Everything would need to be
security checked again before it could be deployed.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

K. Peachey
In reply to this post by Jeroen De Dauw-2
On Fri, Jul 30, 2010 at 11:44 PM, Jeroen De Dauw <[hidden email]> wrote:

> ..snip..
> I totally agree here with Ryan. The idea is to have the "repository" where
> the version data is fetched is configurable, so it's possible to have other
> distributors then the WMF, and to turn of the feature entirely.
>
> I'm currently looking into the repository and package fetching parts do
> allow for such "dialling home". MediaWiki.org seems the obvious choice to
> have the main repository on. There are many ways to then provide the needed
> data. Personally I think the best approach would be to install Semantic
> MediaWiki (yes, I used the s-word!) so data from the extension pages can be
> queried and shown in a distribution metadata format. That might require a
> small extension for some new spacial pages, and some scripts to collect
> other existing version data and put it into the wiki.
>
> Is it possible to get SMW onto MW.org? This would also finally be a proof of
> concept of SMW on a WMF wiki, on which a lot of people have been waiting a
> long time now.
>
> With only a little over 3 weeks left in GSoC, I have little doubt this
> project will not be finished, so any help in any form is definitely welcome.
>
>
> [0] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Deployment
I don't think on-wiki would be the best way for this, espically for
the extensions within our SVN, because you would have to list the
revision that it needs against the version number and the version of
the extension. and then for the ones we don't have in our SVN you
would need to store their download format (http/git/svn etc) and
location as well.

You would also need to be vigilant and make sure people don't
vandalize the information, For example if a spam version change got
entered and broke someones installed.

-Peachey

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Aryeh Gregor
In reply to this post by K. Peachey
On Fri, Jul 30, 2010 at 10:28 PM, K. Peachey <[hidden email]> wrote:

>  I would highly unrecommended having the update feature in there, we
> already highly recommend against running as a db user with certain
> admins rights amongst other things, this feature will probably end up
> breaking more installs then updating (and yes I know wordpress has it,
> and I know how many times i've had to fix their botch updates), and
> not all installs would have the required modules that it needs
> (cURL/wGet comes to mind on IIS setups which some people use). Nor
> should we be assigning the update right or giving messages to the
> admin group by default, since most people that are admins are non
> technical and will just click any bright button that has messages
> along the lines of "omg update me now" without thinking if it will
> break something (Perhaps we should un-deprecate the developer
> usergroup for this).

If I'm interpreting this right, you're saying that upgrades can break
stuff, so people should stick to versions with known security flaws.
This is a defensible position in practice, but it doesn't justify
making upgrades unnecessarily hard.  It would be a good thing if
typical admins could easily upgrade, without needing FTP access and so
forth.  If they choose not to, that's their choice, but if they want
to upgrade, they should be able to do so easily.

On Fri, Jul 30, 2010 at 10:55 PM, K. Peachey <[hidden email]> wrote:
> You would also need to be vigilant and make sure people don't
> vandalize the information, For example if a spam version change got
> entered and broke someones installed.

Any kind of auto-update mechanism should be hardcoded to retrieve only
from a specific Wikimedia URL and only over HTTPS, and the contents of
that URL should only be changeable by sysadmins.  Or at least the
checksum should be retrieved that way.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

David Gerard-2
On 1 August 2010 19:14, Aryeh Gregor <[hidden email]> wrote:

> If I'm interpreting this right, you're saying that upgrades can break
> stuff, so people should stick to versions with known security flaws.
> This is a defensible position in practice, but it doesn't justify
> making upgrades unnecessarily hard.


I assume this is based on WordPress, where this happening was a bit of
a problem for a while. These days it works pretty flawlessly. (3.0.1
is just out, I should probably install it.)


>  It would be a good thing if
> typical admins could easily upgrade, without needing FTP access and so
> forth.  If they choose not to, that's their choice, but if they want
> to upgrade, they should be able to do so easily.


WordPress asks for the account's SFTP password, which I don't find
feels like an undue imposition.

Basically, such a mechanism will be compared to WordPress every step
of the way :-)


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Edward Z. Yang-2
In reply to this post by Tim Starling-2
Hello Tim,

I'd like to contribute a somewhat different (although I suppose
common) perspective to this discussion.  I help run a free-for-the-community
shared webhosting service, and one of the services we have is "automatic
installation" of common web applications for people who don't know
very much about setting up or deploying applications.  Wordpress and
MediaWiki are among our most popular installations.

Since it's not reasonable to assume someone who can click a button to
setup an application has the know-how to upgrade it manually, any
installation that we autoinstall also comes with an upgrade promise:
when new versions of the application come out, we reserve the right to
automatically upgrade the application for you.  (Since we allow users
to patch their installs, there are some, ah, technical difficulties associated
with this.)

We've noticed several things:

    - When Wordpress 3.0 came out, we received several support tickets
      asking us when we would be pushing an upgrade, and asked us if
      anything bad would happen if they went ahead and upgraded their
      install themselves.  We have /never/ had this happen for MediaWiki.

    - Our spread of versions is quite interesting:

wordpress            649 installs
    2.0.2      *       5  +
    2.0.4              7  +
    2.0.11             4  +
    2.1.3              1  +
    2.3                2  +
    2.3.2      *       1  +
    2.3.3      *      29  ++
    2.5.1      *      17  ++
    2.6                1  +
    2.6.2              2  +
    2.6.3              2  +
    2.7                2  +
    2.7.1      *      15  +
    2.8        *       8  +
    2.8.1              1  +
    2.8.2      *       2  +
    2.8.4      |       6  +
    2.8.5      |       3  +
    2.9        |       2  +
    2.9.1      |       4  +
    2.9.2      |      74  +++++
    3.0        |     461  ++++++++++++++++++++++++++++++

mediawiki            1017 installs
    1.5.8      *     118  ++++++
    1.11.0     *     125  ++++++
    1.14.0     *       6  +
    1.15.0     *       6  +
    1.15.1     |      65  +++
    1.15.2     |      15  +
    1.15.3     |      18  +
    1.15.4     |     664  ++++++++++++++++++++++++++++++

      Applications that are on older versions we attempted to upgrade, but had
      to bail out because there were nontrivial merge conflicts (that is, the user
      had edited some core files and the upgrade would have obliterated those
      changes)--there are some exceptions but that is the primary mode by which
      upgrades failed.

      The Star means that we offered installation of that version.  Our upgrade
      process was spotty until about a year and a half ago, when we started really
      making sure we tracked upstream versions closely.

There are certainly some conclusions to be made here, including "When people
patch MediaWiki, they patch it in a way that's really hard to upgrade" and
"People don't upgrade MediaWiki by themselves" (note that Wordpress has a spread
of versions all over the place, whereas every MediaWiki was from a version we
supported."

Let me know if you have any questions; I'd be happy to run other queries
on our setup.

Cheers,
Edward

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Platonides
Edward Z. Yang wrote:
> We've noticed several things:
>
>     - When Wordpress 3.0 came out, we received several support tickets
>       asking us when we would be pushing an upgrade, and asked us if
>       anything bad would happen if they went ahead and upgraded their
>       install themselves.  We have /never/ had this happen for MediaWiki.

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)


> mediawiki            1017 installs
>     1.5.8      *     118  ++++++
>     1.11.0     *     125  ++++++
>     1.14.0     *       6  +
>     1.15.0     *       6  +
>     1.15.1     |      65  +++
>     1.15.2     |      15  +
>     1.15.3     |      18  +
>     1.15.4     |     664  ++++++++++++++++++++++++++++++
>
>       Applications that are on older versions we attempted to upgrade, but had
>       to bail out because there were nontrivial merge conflicts (that is, the user
>       had edited some core files and the upgrade would have obliterated those
>       changes)--there are some exceptions but that is the primary mode by which
>       upgrades failed.
>
>       The Star means that we offered installation of that version.  Our upgrade
>       process was spotty until about a year and a half ago, when we started really
>       making sure we tracked upstream versions closely.

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

> There are certainly some conclusions to be made here, including "When people
> patch MediaWiki, they patch it in a way that's really hard to upgrade" and
> "People don't upgrade MediaWiki by themselves" (note that Wordpress has a spread
> of versions all over the place, whereas every MediaWiki was from a version we
> supported."

There's probably some interesting knowledge on looking how they patched
it, but I don't know how to easily extract it.



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Edward Z. Yang-2
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Platonides
Edward Z. Yang wrote:
>> 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

I'm open for any data :)
My guess is that the most edited files are the skins. Then perhaps
message files (instead of using the MediaWiki namespace) and maybe the
Linker/Parser.
It's likely our fault, too. We should perform a review the advices at
www.mediawiki.org and archive the outdated ones which require patching.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

K. Peachey
In reply to this post by Aryeh Gregor
On Mon, Aug 2, 2010 at 4:14 AM, Aryeh Gregor
<[hidden email]> wrote:
> If I'm interpreting this right, you're saying that upgrades can break
> stuff, so people should stick to versions with known security flaws.
> This is a defensible position in practice, but it doesn't justify
> making upgrades unnecessarily hard.  It would be a good thing if
> typical admins could easily upgrade, without needing FTP access and so
> forth.  If they choose not to, that's their choice, but if they want
> to upgrade, they should be able to do so easily.
No I'm saying not to use a automated update version within a extension
which for example has been shown to break things in other web based
packages (Wordpress has apparently fixed it since the horrible times
when i last attempted). What about the maintenance scripts people have
to run? such as the updater, alot of people on shared hosting can't do
those as it is without re-running the installer since they aren't
allowed ssh access and ours aren't designed to be run from within the
browser window.

> Any kind of auto-update mechanism should be hardcoded to retrieve only
> from a specific Wikimedia URL and only over HTTPS, and the contents of
> that URL should only be changeable by sysadmins.  Or at least the
> checksum should be retrieved that way.
So every-time someone that creates/modifies a extension wants to
update its version number? which is why it was recommended to go wiki
base, but that as well has it flaws.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki version statistics

Aryeh Gregor
On Sun, Aug 1, 2010 at 6:27 PM, K. Peachey <[hidden email]> wrote:
> No I'm saying not to use a automated update version within a extension
> which for example has been shown to break things in other web based
> packages (Wordpress has apparently fixed it since the horrible times
> when i last attempted).

I don't follow you.

> What about the maintenance scripts people have
> to run? such as the updater, alot of people on shared hosting can't do
> those as it is without re-running the installer since they aren't
> allowed ssh access and ours aren't designed to be run from within the
> browser window.

Obviously, that would be changed.

> So every-time someone that creates/modifies a extension wants to
> update its version number? which is why it was recommended to go wiki
> base, but that as well has it flaws.

I really don't think it would be a good idea to allow unvetted code to
be downloaded and installed automatically.  That's too easy for an
attacker to abuse.  But it's probably a reasonable tradeoff for some
people.  I don't know, I'm probably not going to be working on this
anytime soon, so I don't make the decisions.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
1234