Last modified: 2012-11-21 05:31:26 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 T43778, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41778 - IPv6 range blocks aren't working on Meta-Wiki
IPv6 range blocks aren't working on Meta-Wiki
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
1.21.x
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
: ipv6
Depends on:
Blocks: SWMT
  Show dependency treegraph
 
Reported: 2012-11-05 13:07 UTC by Trijnstel
Modified: 2012-11-21 05:31 UTC (History)
12 users (show)

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


Attachments

Description Trijnstel 2012-11-05 13:07:13 UTC
As an example; 2605:8900:5000:1001:6:0:E:2 is recently used by a long-term vandal.

The local IPv6 range block is working on nlwiki and globally:
* https://nl.wikipedia.org/wiki/Speciaal:Blokkeerlijst/2605:8900:5000:1001:6:0:E:2
* https://meta.wikimedia.org/wiki/Special:GlobalBlockList/2605:8900:5000:1001:6:0:E:2

But it's not working on meta:
* https://meta.wikimedia.org/wiki/Special:BlockList/2605:8900:5000:1001:6:0:E:2 ("The requested IP address or username is not blocked.")

While I did block the range recently:
* https://meta.wikimedia.org/wiki/Special:Contributions/2605:8900::/32

I noticed it earlier already, but this is a clear example. Please fix it.
Comment 1 Trijnstel 2012-11-05 13:09:07 UTC
This is a major bug as global blocks don't apply on meta...
Comment 2 Marcin Cieślak 2012-11-05 13:12:43 UTC
Do you know if the range block does not work (i.e. users from this range
can edit) or it's just not displayed in the Special:BlockList output?
Special:Contributions suggest that the address range is blocked indeed.
Comment 3 Trijnstel 2012-11-05 13:14:44 UTC
I know it's not working sadly. Again, for the most recent example. 2605:8900:5000:1001:6:0:E:2 was the underlying IP of this vandal account -> https://meta.wikimedia.org/wiki/Special:Contributions/Mo%C3%ACraMo%C3%ACraMo%C3%ACra (used on 5 Nov 2012 and the IPv6 range was blocked on 1 Nov 2012)
Comment 4 Andre Klapper 2012-11-06 10:49:40 UTC
(In reply to comment #0)
> The local IPv6 range block is working on nlwiki and globally:
> But it's not working on meta:

Sounds rather like an issues with the servers than MediaWiki software to me. Moving from Mediawiki product to Wikimedia.
Comment 5 Andre Klapper 2012-11-06 11:14:27 UTC
<saper> andre__: re https://bugzilla.wikimedia.org/show_bug.cgi?id=41778 I am not sure it's "site config" thing... my wild guess is the order the blocks are checked when GlobalBlock comes into play

Hence moving back.
Comment 6 Jasper Deng 2012-11-18 00:40:42 UTC
I think we can mark this as a dup of https://bugzilla.wikimedia.org/show_bug.cgi?id=37481
Comment 7 Jasper Deng 2012-11-18 00:43:17 UTC
In addition, I do think this does have something to do with GlobalBlocking. Before I started using GlobalBlocking on my own (private) wikis, local rangeblocks were effective.
Comment 8 MZMcBride 2012-11-18 00:52:54 UTC
(In reply to comment #6)
> I think we can mark this as a dup of
> https://bugzilla.wikimedia.org/show_bug.cgi?id=37481

Well, then you say...

(In reply to comment #7)
> In addition, I do think this does have something to do with GlobalBlocking.
> Before I started using GlobalBlocking on my own (private) wikis, local
> rangeblocks were effective.

Before (at bug 37481 comment 3), you said...

> [...]
> 
> I doubt GlobalBlocking is the problem here. I don't know if I can reproduce it
> on my own wikis since they don't use 1.20wmf5.

So, no, I don't think we can safely mark as a dupe right now. You seem a bit conflicted about where the problem is and the symptoms seem distinct.

---

Regarding this particular bug, I thought there was some kind of historical exemption for global blocks for Meta-Wiki so that Meta-Wiki could act as a court of last resort or something. Am I wrong about that? It may end up meaning more work for stewards, but I'm not sure global blocks not applying at Meta-Wiki (in particular as it's a global hub wiki) is a bug, per se.
Comment 9 Jasper Deng 2012-11-18 00:53:52 UTC
(In reply to comment #8)
> (In reply to comment #6)
> > I think we can mark this as a dup of
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=37481
> 
> Well, then you say...
> 
> (In reply to comment #7)
> > In addition, I do think this does have something to do with GlobalBlocking.
> > Before I started using GlobalBlocking on my own (private) wikis, local
> > rangeblocks were effective.
> 
> Before (at bug 37481 comment 3), you said...
> 
> > [...]
> > 
> > I doubt GlobalBlocking is the problem here. I don't know if I can reproduce it
> > on my own wikis since they don't use 1.20wmf5.
> 
> So, no, I don't think we can safely mark as a dupe right now. You seem a bit
> conflicted about where the problem is and the symptoms seem distinct.
> 
> ---
> 
> Regarding this particular bug, I thought there was some kind of historical
> exemption for global blocks for Meta-Wiki so that Meta-Wiki could act as a
> court of last resort or something. Am I wrong about that? It may end up meaning
> more work for stewards, but I'm not sure global blocks not applying at
> Meta-Wiki (in particular as it's a global hub wiki) is a bug, per se.

(I'm rescinding my previous statement with that comment)
Comment 10 MZMcBride 2012-11-18 00:55:02 UTC
(In reply to comment #8)
> Regarding this particular bug, I thought there was some kind of historical
> exemption for global blocks for Meta-Wiki so that Meta-Wiki could act as a
> court of last resort or something. Am I wrong about that? It may end up meaning
> more work for stewards, but I'm not sure global blocks not applying at
> Meta-Wiki (in particular as it's a global hub wiki) is a bug, per se.

Or even more than a court of last resort, really: if you globally block a range like this, where do people report issues or errors with the block?
Comment 11 MZMcBride 2012-11-18 01:14:54 UTC
This bug is currently marked high importance, major bug, but I'm not sure there's any evidence of that. Is there any evidence of edits or actions post-local Meta-Wiki block on this range?

Global blocks are not supposed to apply at Meta-Wiki. So that's not really a bug. But if, after you also locally blocked the range, there are edits, that would be a major bug. I haven't seen any evidence of this.

I _think_ there's a generic issue here where blocked individual IPv6 (and maybe v4 as well) addresses don't "know" or don't _report_ that they're blocked everywhere you might check. But, again, if it's just a reporting issue and there the local block is working as expected (and the global block is also working as expected for that matter), then the priority/importance of this bug can be dramatically lowered.
Comment 12 Trijnstel 2012-11-18 10:30:40 UTC
(In reply to comment #6)
> I think we can mark this as a dup of
> https://bugzilla.wikimedia.org/show_bug.cgi?id=37481

I'm not sure about that. Of course, it's possible. But I had the impression that local IPv6 blocks ánd global blocks were working; only on meta I saw problems.
Comment 13 Trijnstel 2012-11-18 10:41:45 UTC
(In reply to comment #11)
> This bug is currently marked high importance, major bug, but I'm not sure
> there's any evidence of that. Is there any evidence of edits or actions
> post-local Meta-Wiki block on this range?
> 
> Global blocks are not supposed to apply at Meta-Wiki. So that's not really a
> bug. But if, after you also locally blocked the range, there are edits, that
> would be a major bug. I haven't seen any evidence of this.
> 
> I _think_ there's a generic issue here where blocked individual IPv6 (and maybe
> v4 as well) addresses don't "know" or don't _report_ that they're blocked
> everywhere you might check. But, again, if it's just a reporting issue and
> there the local block is working as expected (and the global block is also
> working as expected for that matter), then the priority/importance of this bug
> can be dramatically lowered.

Actually, it is a major bug. I saw it happening multiple times and I can give you the evidence if you want. To proceed with the original example of the abuse of IPv6 address 2605:8900:5000:1001:6:0:E:2. Here's the timeline:

* 1 Nov 2012 12:40-12:42 - he vandalized on meta with 2605:8900:5000:1001:6:0:10C:2 (edits hidden) and therefore I decided to locally block the IPv6 range on meta -> http://meta.wikimedia.org/wiki/Special:Contributions/2605:8900:0:0:0:0:0:0/32 (this range was already globally blocked by Jyothis in July 2012 for a year)
* 5 Nov 2012 10:34-10:39 - he continued on meta with the account "MoìraMoìraMoìra" (https://meta.wikimedia.org/wiki/Special:Contributions/Mo%C3%ACraMo%C3%ACraMo%C3%ACra); a checkuser looked at the underlying IP and it turned out to be 2605:8900:5000:1001:6:0:E:2 (which falls in the /32 range I already blocked on 1 Nov 2012). It was a hardblock, so in theory no one should be able to create an account and use it on meta... it did happen though.

I have no evidence that it happened on other projects outside meta, but it's not impossible of course. And yes, the rule still stands that meta is the only project not affected by global blocks, but as I locally blocked this range and the vandal was still able to create and use accounts... that's just wrong.
Comment 14 Jasper Deng 2012-11-18 20:37:35 UTC
(In reply to comment #12)
> (In reply to comment #6)
> > I think we can mark this as a dup of
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=37481
> 
> I'm not sure about that. Of course, it's possible. But I had the impression
> that local IPv6 blocks ánd global blocks were working; only on meta I saw
> problems.

True, global blocks appear to be working. However, my experiment on testwiki shows that it isn't limited to Meta only.
Comment 15 Tim Starling 2012-11-18 22:21:46 UTC
ipb_range_start and ipb_range_end have the wrong field size on 675 out of 863 wikis, and metawiki happens to be one of those 675. They seem to be using varbinary(8).

I'm not sure how the field came to be so small. It was introduced as varchar(32), and expanded to tinyblob in MW 1.8.
Comment 16 Tim Starling 2012-11-18 22:22:56 UTC
Added Asher to the CC list.
Comment 17 Tim Starling 2012-11-18 23:49:43 UTC
I'm writing a script to fix this.
Comment 18 Tim Starling 2012-11-19 00:56:13 UTC
Fixed.
Comment 19 Asher Feldman 2012-11-20 20:54:47 UTC
(In reply to comment #16)
> Added Asher to the CC list.

FWIW, the only migrations I ran to prep for enabling ipv6 traffic were against SecurePoll, GlobalBlocking, and recentchanges, from working off of http://www.mediawiki.org/wiki/IPv6_support_roadmap.
Comment 20 Jasper Deng 2012-11-21 05:31:26 UTC
(In reply to comment #19)
> (In reply to comment #16)
> > Added Asher to the CC list.
> 
> FWIW, the only migrations I ran to prep for enabling ipv6 traffic were against
> SecurePoll, GlobalBlocking, and recentchanges, from working off of
> http://www.mediawiki.org/wiki/IPv6_support_roadmap.

I also thought you ran migrations in ipblocks per http://wikitech.wikimedia.org/view/Server_admin_log/Archive_20#May_16

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


Navigation
Links