[wp-trac] [WordPress Trac] #23394: Remove version from readme.html / Upgrade core doesn't restore the file

[WordPress Trac]

#23394: Remove version from readme.html / Upgrade core doesn't restore the file
---------------------------+----------------------
 Reporter:  momo360modena  |       Owner:
     Type:  enhancement    |      Status:  closed
 Priority:  normal         |   Milestone:
Component:  General        |     Version:
 Severity:  normal         |  Resolution:  wontfix
 Keywords:                 |     Focuses:
---------------------------+----------------------
Changes (by chriscct7):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 IETF's recommendation 14.39 in RFC 2038 refers to a header that was
 previously used for intra-network communication for use in identifying the
 processing software or for general use server surveys. This specific
 header would contain information about a level that is higher than the
 application layer of WordPress, and thus should not be construed as
 guidance to projects like WordPress or other software that runs at the
 same layer as WordPress. An example of data previously contained in this
 header was:
 > CERN/3.0 libwww/2.17

 This header no longer exists. In fact the RFC you referenced was written
 in 1997, and was itself invalidated and supersceded by RFC 2616 in 1999.
 As of the 1999 RFC, no RFCs since, about the HTTP protocol have contained
 similar guidance, partially because the header in question doesn't exist
 beginning in RFC 2616.

 The license.txt file contains the GPL license text which is a component of
 the GPL license which WordPress uses.

 > Regarding removing version numbers from CSS and JS files: As I mentioned
 above, replace the version number with a salted hash (or other unique
 random key) that changes each time the version is updated.

 This would break backwards compatibility that plugins can rely on, and it
 doesn't solve the problem that it's just as easy to compare the contents
 of the file as it is to parse the version out of the url.

 Moreover, there appears to be a suggestion that even if you remove these
 files, hide the meta generator tag, and randomize the version appended to
 strings, somehow that will plug all of your version concerns. However, if
 one really wants the version number you can simply run a string comparison
 on the outputted css or js files. Moreover, the WordPress REST API
 framework requires versioning, which inherently must be public in order
 for the feature to use, and that versioning can be directly mapped to
 versions of WordPress. That itself cannot be prevented.

 > We have to assume that sooner or later, a vulnerability will be found in
 every single version of WordPress.

 Using a version detection library attached to a standard exploit library
 set such as metasploit, one can simply just run through all
 vulnerabilities ever found for WordPress just as quickly as detecting the
 version on a site that's done what you've prescribed. The fact of the
 matter is that security by obscurity (version hiding being an example),
 does not make the site any more or less secure (as pointed out in the
 OWASP). In actuality in certain penetration software it makes it faster.
 Many frameworks, upon being unable to deduce a version number of an
 application, simply iterate over all vulnerabilities anyways.

 > Very true...but WordPress.org's own usage stats show that approximately
 48% of WordPress users aren't even updated to the 4.4 (current) branch so
 that leaves about half of WordPress' users out of luck if a more proactive
 approach to security isn't taken.

 This is a soon to be obsolete argument. WordPress is moving towards
 Chromium style updates, where major versions are done automatically.
 Existing tail end WordPress installs are automatically being updated major
 versions now, even if they were not previously by a combination of
 WordPress outreach to major web hosting companies and other relevant
 parties. As this continues to occur, the number of sites on the current
 major version in perpetuity will continue to grow. It wouldn't surprise me
 if after 2 years, that's up to 85-90% of all installs always on the
 current major version.

 Furthermore, on sites where WordPress has autoupdate minor releases (all
 sites since 3.7, so about 80%+ of all WP installs), any newly discovered
 vulnerabilities can be pushed and patched in real time. Hiding versions
 does not in any way, shape or form help make any site newer than 3.7 more
 secure than they already were.

 > It's also being proposed to add the WP version number in Etags, and this
 is already implemented in v4.5-RC2, which is also not a great idea. Please
 see [https://core.trac.wordpress.org/ticket/28722#comment:25 my comments]
 on the [https://core.trac.wordpress.org/ticket/28722#comment:27 ticket
 here].

 That's not a proposal, it's a merged feature that will ship with WordPress
 4.5 in 2 days.

 > Not revealing version numbers is merely one aspect of following
 establshed good security principles, so this shouldn't be seen as an odd
 request. I've seen requests similar to this keep getting shut down over
 the years and it makes me scratch my head.
 >
 > '''If we can make some relatively easy changes to remove all the version
 number leakage throughout WordPress, and reduce the number of successful
 hacks (even if only by a small percent), for ''nearly half of WordPress
 users'' that don't upgrade as quickly, doesn't it seem like that's
 something we should do?'''

 These are only successful because either users fail to upgrade major
 versions (something that again will not be as significant if at all an
 issue in the future) or have something else that's vulnerable, generally a
 plugin, which does not in any way have anything to do with WordPress
 version number "leakage". In the meantime, the users who don't upgrade
 will never see this update to remove the version numbers, so in the end,
 this type of thing provides a net benefit of helping no one. A site is
 either up to date and thus secure via security releases, or doesn't update
 and will never see this update anyway.

 Note, I'm going to reclose this ticket, however, a closed ticket does not
 mean discussion has to stop. You (and others) can continue commenting on
 the ticket while it is closed.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/23394#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform