[wp-trac] [WordPress Trac] #16778: wordpress is leaking user/blog information during wp_version_check()
noreply at wordpress.org
Wed Dec 7 16:50:32 UTC 2016
#16778: wordpress is leaking user/blog information during wp_version_check()
Reporter: investici | Owner:
Type: enhancement | Status: reopened
Priority: normal | Milestone:
Component: Administration | Version:
Severity: minor | Resolution:
Keywords: has-patch | Focuses:
Comment (by Otto42):
> Not sure how would number of registered users or blogs help, especially
during version check.
Specifically, this code was imported during the merge of WordPress to
WordPress-MU, when multisite was added. The reason for this particular
data being sent has to do with the possible necessity of providing
alternate upgrade paths for large installations.
When in multisite mode, WordPress stores each site in the network as a
separate set of tables. For anybody who has done an update on such a site,
you'll know that there is an "Update Network" process which runs through
each of those tables performing any changes to them that may have happened
in the update. These can be as simple as running some queries to update a
few rows in the options table, or entire schema adjustments. While this
process is fine for smaller installations, it won't work on truly big
installations. Too slow, basically.
The "number of blogs" is thus sent back in case there is some major update
to the schema that might require the dev team to create a separate update
path. It's one thing to have a couple of blogs do some schema changes, but
multisite instances exist with hundreds of thousands of sets of tables.
Those sites might need special handling at some future point. It has not
happened yet, but it is certainly possible.
The "number of users" information is for the same reason. Large multisite
instances can have tens of millions of rows in the users table. Schema
changes to that table can literally cripple sites and bring them to a
screeching halt. Such large updates might need special handling if the
users table schema changes (and that has happened before).
So, these checks exist in the API just in case an update ever needs to be
created specially for larger instances of WordPress. They were added to
the update checks solely for that reason. They're not there specifically
for data gathering purposes.
If you wish to filter the data for privacy purposes, then you can do so
and it will not affect the update process for small WordPress
installations. At present, there is not a secondary update path for large
installations, but that does not preclude the possibility of one occurring
in the future.
Ticket URL: <https://core.trac.wordpress.org/ticket/16778#comment:67>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac