Last modified: 2013-05-25 10:50:41 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T50791, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 48791 - XFF ranges needs updating with Opera range
XFF ranges needs updating with Opera range
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Unprioritized enhancement (vote)
: ---
Assigned To: Sam Reed (reedy)
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-24 17:12 UTC by kwwilliams
Modified: 2013-05-25 10:50 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description kwwilliams 2013-05-24 17:12:12 UTC
I've discovered a large range of IPV6 addresses used by Opera that are being used as proxies for Opera browser users. When the "turbo" mode is selected, the Opera server is the one that actually accesses the website, and it sends a compressed version to the user. I've been assured by DeltaQuad and DepartmentOfRedudancyDepartment that the servers are sending valid XFF headers. I can't see any reason to believe that Opera would forge headers to falsely implicate Wikipedia editors, so we need to have the Opera servers in the range 2001:4c28::/32 configured to be "trusted" XFF servers.

As an intermediate solution, I have blocked all anonymous editing through this range on English Wikipedia.

I also invite comments on whether this is the best way to handle this. This seems to be something that any checkuser should be able to configure on a per-wiki basis. Is it, and our current batch of checkusers was never told how? Or does it actually require action at the Wikimedia software level?
Comment 1 MZMcBride 2013-05-24 17:44:23 UTC
I wonder if this is a MediaWiki issue or a Wikimedia issue.
Comment 2 Alex Monk 2013-05-24 19:26:50 UTC
Undoubtedly Wikimedia.

(In reply to comment #0)
> I also invite comments on whether this is the best way to handle this. This
> seems to be something that any checkuser should be able to configure on a
> per-wiki basis. Is it, and our current batch of checkusers was never told
> how?
> Or does it actually require action at the Wikimedia software level?

No, I'm pretty sure this requires changes to the software or configuration.
Comment 3 Sam Reed (reedy) 2013-05-24 20:10:56 UTC
(In reply to comment #2)
> Undoubtedly Wikimedia.
> 
> (In reply to comment #0)
> > I also invite comments on whether this is the best way to handle this. This
> > seems to be something that any checkuser should be able to configure on a
> > per-wiki basis. Is it, and our current batch of checkusers was never told
> > how?
> > Or does it actually require action at the Wikimedia software level?
> 
> No, I'm pretty sure this requires changes to the software or configuration.

No.

trusted-hosts.txt in the TrustedXFF extension need updating.

Then the cdb needs updating/rebuilding and then be pushed to the cluster

For examaple:

# Opera Mini
# Source: https://list.opera.com/mailman/listinfo/net-changes-mini
37.228.104.0/21
58.67.157.0/24
59.151.95.128/25
59.151.98.128/27
59.151.106.224/27
59.151.120.32/27
80.84.1.0/24
80.239.242.0/23
82.145.208.0/20
91.203.96.0/22
116.58.209.36/27
116.58.209.128/27
141.0.8.0/21
195.189.142.0/23
203.81.19.0/24
209.170.68.0/24
217.212.226.0/24
217.212.230.0/23
Comment 4 kwwilliams 2013-05-24 22:23:03 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Undoubtedly Wikimedia.
> > 
> > (In reply to comment #0)
> > > I also invite comments on whether this is the best way to handle this. This
> > > seems to be something that any checkuser should be able to configure on a
> > > per-wiki basis. Is it, and our current batch of checkusers was never told
> > > how?
> > > Or does it actually require action at the Wikimedia software level?
> > 
> > No, I'm pretty sure this requires changes to the software or configuration.
> 
> No.
> 
> trusted-hosts.txt in the TrustedXFF extension need updating.
> 
> Then the cdb needs updating/rebuilding and then be pushed to the cluster

Two "no"s in a row there, and I'm unsure whether the second no is another "no" to me or if it's a "no" to the first "no".

Who has the power to update trusted-hosts.txt, rebuild the CDB, and push it to a cluster. Is that under English Wikipedia control, or is it under centralized control?
Comment 5 Sam Reed (reedy) 2013-05-24 22:49:17 UTC
No, it's not under English Wikipedia control. Little is.

Anyone with a gerrit account can add it to trusted-hosts.txt

A more limited group of people have the rights to approve and that change

And an even much limited group can merge that to the deployment branch, update the code on the cluster...
Comment 6 Gerrit Notification Bot 2013-05-24 22:50:12 UTC
Related URL: https://gerrit.wikimedia.org/r/65344 (Gerrit Change Id337b820773971559636313ad2300bbf290d9b1a)
Comment 7 kwwilliams 2013-05-24 22:58:42 UTC
This really seems like a roundabout way to address what should be simple day-to-day maintenance. Is there a reason that the extension can't consult a locally-configured list?
Comment 9 Matthew Flaschen 2013-05-25 00:03:16 UTC
I made a note that changes can be proposed through Gerrit.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links