Last modified: 2013-07-25 07:07:22 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 T49626, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 47626 - TorBlock catches Tor relay node
TorBlock catches Tor relay node
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
TorBlock (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Tyler Romeo
:
Depends on:
Blocks: SWMT
  Show dependency treegraph
 
Reported: 2013-04-25 02:53 UTC by king.of.hearts.wiki
Modified: 2013-07-25 07:07 UTC (History)
11 users (show)

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


Attachments

Description king.of.hearts.wiki 2013-04-25 02:53:16 UTC
173.164.206.181 is a Tor relay node and not a Tor exit node, as it appears from http://torstatus.blutmagie.de/router_detail.php?FP=25871bf90689b270bb6fe873f9c72760ab026dd1. However, it is blocked automatically by TorBlock as an exit node. The operator states that he has never run a Tor exit node on that IP before. Could you check on how this IP managed to be affected by TorBlock?
Comment 1 Sam Reed (reedy) 2013-04-26 01:08:32 UTC
I'm presuming this is "broken" on Wikimedia wikis?
Comment 2 king.of.hearts.wiki 2013-04-26 01:11:59 UTC
Yes, because it is a global block imposed by the software.
Comment 3 Akeron 2013-04-28 15:32:47 UTC
I received an e-mail from an user blocked by this extension, he is running a relay (not an exit node), I gived him an IP block exempt on french Wikipedia. This is the first time I see this problem, maybe something changed recently ?
Comment 4 Andre Klapper 2013-04-29 10:08:39 UTC
agarrett: Could you take a look at this?
Comment 5 Kunal Mehta (Legoktm) 2013-05-02 16:58:13 UTC
Bumping up the priority on this, there are a bunch of users coming on IRC/via OTRS who are running relay nodes and being caught.
Comment 6 Sam Reed (reedy) 2013-05-02 17:01:20 UTC
(In reply to comment #4)
> agarrett: Could you take a look at this?

Most likely probably not
Comment 7 Haakon Nilsen 2013-05-02 17:05:43 UTC
This is my Tor relay: http://torstatus.blutmagie.de/router_detail.php?FP=08290c45ad407034c17ea9e6650689b5fe98996a

It is not an exit node, and it never has been or will be. I would like to be able to edit Wikipedia, which I have been doing for 10 years prior to this.
Comment 8 Sam Reed (reedy) 2013-05-02 17:09:45 UTC
There has been pretty much no development done to the extension anytime recently (since January maybe?).

I made some changes recently, but that was configuration changes to allow us to make the request using a proxy.

Does anyone know if anything has changed upstream? With the lack of changes here, and it seemingly suddenly breaking, the probably would seemingly be from where the information source is..
Comment 9 Chris Steipp 2013-05-02 17:36:16 UTC
I'm guessing with access to the proxy, the onionoo list has started to be loaded where it previously wasn't. It looks like the code is blocking everything on that list, without checking if they're exit nodes or not.

Can we block onionoo.torproject.org at the proxy for now, so it falls back to check.torproject.org for now?
Comment 10 Tyler Romeo 2013-05-02 18:14:50 UTC
Hmm, this was my mistake. It seems I misread the documentation for Onionoo. When you access the summary documents, it seems Onionoo lists all IP addresses for all nodes, rather than just exit addresses.

Currently, I have a patch here: https://gerrit.wikimedia.org/r/53917
This should fix the problem because it uses the detailed summary and only checks exit_addresses, but it's a pretty big patch and does more than just fix this bug. I will work on splitting it up into individual commits so it can be reviewed faster.
Comment 11 Sam Reed (reedy) 2013-05-02 18:59:34 UTC
(In reply to comment #9)
> I'm guessing with access to the proxy, the onionoo list has started to be
> loaded where it previously wasn't. It looks like the code is blocking
> everything on that list, without checking if they're exit nodes or not.

Interesting. Hume should have been able to contact it anyway...
Comment 12 Gerrit Notification Bot 2013-05-02 19:44:14 UTC
Related URL: https://gerrit.wikimedia.org/r/62025 (Gerrit Change Ib15a9ab41ed2d3c2b6e39067e1bd9076a8b6888f)
Comment 13 Tyler Romeo 2013-05-04 21:34:40 UTC
The fix has been merged, so marking as resolved. If somebody could verify when it's next deployed to WMF that'd be great.
Comment 14 Sam Reed (reedy) 2013-05-04 21:45:29 UTC
In theory, it should now be fixed in production..

If anyone can test and confirm whether this is indeed fixed for you, it'd be appreciated
Comment 15 Nemo 2013-05-04 21:47:58 UTC
Is this bug yet another example of how bug 30716 would be a good thing?
Comment 16 Tyler Romeo 2013-05-04 21:50:22 UTC
(In reply to comment #15)
> Is this bug yet another example of how bug 30716 would be a good thing?

Nah, this bug was just a fluke in a previous patch of mine that messed things up because I read documentation wrong.
Comment 17 Haakon Nilsen 2013-05-04 22:11:13 UTC
Confirming that it now works for me, thank you very much.

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


Navigation
Links