It will. Just add more wgExtensionCredits in your LocalSettings.php.

I think this report should be closed INVALID.

For extensions, yes. However, the report is asking about 3rd party things that the software uses that should (possibly) be given at the top with the Apache/MySQL/PHP versions (GDv2, etc). I don't think an end-user should have to dig up all this information and put it into their LocalSettings by hand when the software can return all this for them.

Not to mention, they'd be mislabeled as extensions, which they're not.

Hmmm, this one sounds interesting.

CCing myself, if someone hasn't claimed this sometime later and I'm still interested I'll look into it.

On second look, this seams like this is more trouble than it's worth:

Trying to get the WebServer version:

The output of $_SERVER['SERVER_SOFTWARE'] is highly useless. For me it simply outputs 'nginx', I expect Apache also just outputs 'Apache'.

There's a slight chance of getting a process name using the pid from postix_getpid (Only works on *nix), but if PHP is being run in fcgi then that's just going to get the name of PHP.

Alternatively $_SERVER['SERVER_SOFTWARE'] could be used to understand what software is being run. Then we could code a bunch of different version checks. Though, those would fail if someone installs their WebServer off path.

I looked into Operating System as well for the hell of it. But that's pretty useless to. PHP_OS is highly useless, no version and on any *nix system it outputs 'Linux', which with all the distros is completely useless. posix_uname is also useless, the version is a release time, and the 'release' is a useless sort of version. And again, it outputs 'Linux' as the OS name.

Getting the version of GD proves to be much easier it seems (if they're using GD for their image handling).

$info = gd_info();
$ver = $info['GD Version']

ayg wrote:

For most software, other than maybe PHP extensions, to reliably get versions you'd have to either execute shell commands (uname -a, httpd -v, convert -version, etc.) or do unreliable digging through system files. So it's unlikely you're going to be able to get this to work on a typical shared host anyway. But the idea is a good one, at least as an option, if only anyone cares enough to actually do it.

The version of image thumbnailing engine can be shown as of r52476. Or maybe more softwares or tools can be added to the field?

The version of diff3/diff can be shown as of r54286. I think the another idea is to put the SVG renderor's version into Special:Version. However the various path and parameters of the SVG renderor are need to handled properly to show the correct information. :)

Maybe the software used on math function can also be added?

The version of SVG image thumbnailing engine can be shown as of r52516. Only ImageMagick, rsvg and Inkscape are supported for showing the version that they are using.

P.S. on comment 8 that mentioned, the revision committed was r52486 instead of r54286. :)

The version information of the Math rendering engine can be shown as of r52525.

overlordq wrote:

Please make this opt-in, some of us would not like to advertise to the world everything installed and running on our servers.

A config variable like $wgAdvertiseExploitVectors would be apropos

michael.daly wrote:

If it's going to be opt-in, try to arrange it so that admins can see everything at a glance while regular users can only see the more restrictive setting the admin has imposed. That way it isn't exposed to the general public but allows the admin(s) to see what the configuration is. When it comes to installing extensions and such, checking the Version page is one of the debugging steps.

We don't need to integrate this with user rights, it's needless.

I'd suggest something similar to $wgSpecialVersionShowHooks where all this stuff is turned off by default, but can easily be enabled by any wiki admin who wants to (for debugging, etc). $wgAdvertiseExploitVectors is a crap name, though, something like $wgSpecialVersionShowExtendedSoftware would work fine.

(In reply to comment #12)

If it's going to be opt-in, try to arrange it so that admins can see everything
at a glance while regular users can only see the more restrictive setting the
admin has imposed. That way it isn't exposed to the general public but allows
the admin(s) to see what the configuration is. When it comes to installing
extensions and such, checking the Version page is one of the debugging steps.

By assigning a new right for the group can be a good idea for that?
For this, it maybe assigned to sysops by default, and the rights can be extended to other groups by editing the local settings file.

(In reply to comment #14)

(In reply to comment #12)

If it's going to be opt-in, try to arrange it so that admins can see everything
at a glance while regular users can only see the more restrictive setting the
admin has imposed. That way it isn't exposed to the general public but allows
the admin(s) to see what the configuration is. When it comes to installing
extensions and such, checking the Version page is one of the debugging steps.

By assigning a new right for the group can be a good idea for that?
For this, it maybe assigned to sysops by default, and the rights can be
extended to other groups by editing the local settings file.

I reiterate comment #13: we don't need a right for this. Do it with a single config var, off/on, just like hooks.

michael.daly wrote:

The idea that a configuration change is needed for the admin to see the full Version page and that everyone can see the full version page while it is temporarily enabled is not my idea of a good thing. As I said - default for admins and enable/disable for others makes more sense. If admins can do something that others can't, that should be handled by rights assignments to be consistent with the rest of the system. Don't create multiple different means of permitting access to information.

No one ever said that this should be +sysop only except for you.

How is something like this any different from $wgSpecialVersionShowHooks?

ayg wrote:

+sysop by default possibly makes more sense. I'm not sure. What are the use-cases for this?

1. An easy way for sysadmins to check the versions of all relevant software, in case they happen to want to know. This seems marginal.

2. For someone confused about why their installation is working differently from Wikipedia, it might give them the idea to check the package versions. This seems vaguely plausible, if it's enabled on Wikipedia for everyone.

3. For someone requesting support, an easy way for people helping them to get all the relevant version info and so spot any oddities.

For (1) and (2), it would certainly be more useful for it to be enabled for sysops by default. For (3), it still seems easier: you could tell them to paste the info for you instead of having to edit LocalSettings.php, assuming the one asking for help is a sysop. (The best for (3) would be to have it enabled for all viewers by default, but that's probably undesirable.)

I think making a new permission 'versiondetail' or something would be a good idea, set to sysops only by default and everyone on Wikipedia. Maybe even better, extend it to encompass and supersede things like $wgShowExceptionDetails. (It would need a better name then, though.) It would be helpful for the average sysop on a MediaWiki wiki (most probably only have one or two) to be able to view this additional detail by default, but we can't make it world-viewable by default. vBulletin does something like this with database error messages: it prints the failed query for admins only, others get a generic message.

So I'd be in favor of a new permission. It makes more sense to me.

ayg wrote:

(It could include $wgSpecialVersionShowHooks too, of course, unless that's really verbose and debug-gy.)

michael.daly wrote:

Another use case - to see whether the wiki recognizes the 'require_once("...extensionName.php");' placed in LocalSettings.php worked at all. If you have been answering help requests on msusers.com for a long time, you'd recognize how often this is a useful thing. It's the fastest way to get the answer to the question "Are you sure the extension is installed?" As such, this use case is only required for admins.

BTW - as far as differences with $wgSpecialVersionShowHooks: If other features are not handled by rights, that should not influence whether new features should be handled by rights. A global on/off and limited restrictions on actions are not the same thing. Whether $wgSpecialVersionShowHooks should have been restricted to sysops or not is another question. In general, if previous implementations of features have been handled incorrectly, that should be fixed, not used an as example of how to do things in the future.

(In reply to comment #20)

Another use case - to see whether the wiki recognizes the
'require_once("...extensionName.php");' placed in LocalSettings.php worked at
all. If you have been answering help requests on msusers.com for a long time,
you'd recognize how often this is a useful thing. It's the fastest way to get
the answer to the question "Are you sure the extension is installed?" As such,
this use case is only required for admins.

Whether or not an extension is installed is unrelated to the server information now being displayed. Absolutely _none_ of this bug relates to the installed extensions portion of Special:Version.

BTW - as far as differences with $wgSpecialVersionShowHooks: If other features
are not handled by rights, that should not influence whether new features
should be handled by rights. A global on/off and limited restrictions on
actions are not the same thing. Whether $wgSpecialVersionShowHooks should have
been restricted to sysops or not is another question. In general, if previous
implementations of features have been handled incorrectly, that should be
fixed, not used an as example of how to do things in the future.

I suppose I just disagree that this should be handled by rights: I prefer the implementation with $wgSpecialVersionShowHooks.

Frankly I don't see why "Oh no, the public knows I'm using ImageMagick to render my images" is such a big deal that it would be necessary to inject userrights checks into Special:Version, which AFAIK we have never done.

If you don't want people to see version information don't enable the feature, end of story. There are other ways to check what version of software you are running than asking MediaWiki to tell you what you installed and configured. Before this bug came around MW wouldn't even output that information, so I don't see why you need to enable it if you don't want other people to see it.

Special:Version isn't a sysadmin tool, it's a page for the general public to see what is running.

ayg wrote:

(In reply to comment #22)

Frankly I don't see why "Oh no, the public knows I'm using ImageMagick to
render my images" is such a big deal that it would be necessary to inject
userrights checks into Special:Version, which AFAIK we have never done.

We're reporting the exact versions of a lot of software with this feature. If it's outdated, this could be used by attackers. A lot of people would not expect us to do it and would not want it; so we shouldn't do it by default.

(As for what we haven't done before with Special:Version, just ask Domas! He used to use it for timing MediaWiki startup, but realized it eventually ended up running too much extra garbage and he had to invent [[Special:BlankPage]]. :) )

If you don't want people to see version information don't enable the feature,
end of story. There are other ways to check what version of software you are
running than asking MediaWiki to tell you what you installed and configured.
Before this bug came around MW wouldn't even output that information, so I
don't see why you need to enable it if you don't want other people to see it.

IMO it would be potentially useful to be able to have this on by default, at least for sysops. Those who wanted to display it to everyone could do so easily in any event. It's not like group permissions checks are difficult or expensive to do.

Special:Version isn't a sysadmin tool, it's a page for the general public to
see what is running.

I disagree. It's mainly useful for debugging of various kinds, by users at all levels. A lot of people come into MediaWiki-General asking questions and don't know what version they're running, so we point them to Special:Version. More info there could be helpful (although I've never heard of someone with a problematic version of diff . . .).

(In reply to comment #4)

On second look, this seams like this is more trouble than it's worth:
Trying to get the WebServer version:
The output of $_SERVER['SERVER_SOFTWARE'] is highly useless. For me it simply
outputs 'nginx', I expect Apache also just outputs 'Apache'.
There's a slight chance of getting a process name using the pid from
postix_getpid (Only works on *nix), but if PHP is being run in fcgi then that's
just going to get the name of PHP.
Alternatively $_SERVER['SERVER_SOFTWARE'] could be used to understand what
software is being run. Then we could code a bunch of different version checks.
Though, those would fail if someone installs their WebServer off path.
I looked into Operating System as well for the hell of it. But that's pretty
useless to. PHP_OS is highly useless, no version and on any *nix system it
outputs 'Linux', which with all the distros is completely useless. posix_uname
is also useless, the version is a release time, and the 'release' is a useless
sort of version. And again, it outputs 'Linux' as the OS name.

On r52792 was added the feature to showing the version of the web server, if applicable.

For what it's worth, it would be kinda cool and useful to centralize these things into a class somewhere. Maybe a version class with static methods.

Version::php(), Version::webserver(), etc etc. Then they've got a cleaner imeplemtation from the SpecialPage side of it, and they're more useful to things like the API.

overlordq wrote:

Patch to add setting to show/hide extended versioning

This patch does two things.

1. Adds an url when nginx is detected as the server to nginx homepage
2. Creates another setting (which will likely disqualify this patch) which allows you to enable the extended version information. It defaults to off which only shows PHP,MediaWiki,Database as the page originally did.

Attached:

Applied on r53398.

Additionally, the rights 'versiondetail' has been added for sysop by default on the commit too, as on comment 18. If maintainers do not want to show the information for the sysops, use "$wgGroupPermissions['sysop']['versiondetail'] = false;" to suppress them.

matthew.britton wrote:

Yay, another thing the rest of us aren't worthy to see. :(

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

sumanah wrote:

Added "reviewed" keyword since patch was reviewed, and in fact applied, per comment 27.

olivier.beaton wrote:

Wanted to mention I have a statistics engine that aggregates Version information similar with what s23.org does. I pull the webserver out of the headers, and mediawiki/php/database out of :version -- I would love to have more of these on by default. People who are so concerned about attack vectors should really disable a) the version page completely b) the api.

As long as we don't go the route we went before that ended up with the big revert in rSVN54735. That was a little nuts.

External libraries installed via composer are now exposed on Special:Version: https://gerrit.wikimedia.org/r/#/c/182097/