I'm presuming this is "broken" on Wikimedia wikis?

Yes, because it is a global block imposed by the software.

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 ?

agarrett: Could you take a look at this?

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.

(In reply to comment #4)

agarrett: Could you take a look at this?

Most likely probably not

haakonn wrote:

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.

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..

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?

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.

(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...

Related URL: https://gerrit.wikimedia.org/r/62025 (Gerrit Change Ib15a9ab41ed2d3c2b6e39067e1bd9076a8b6888f)

The fix has been merged, so marking as resolved. If somebody could verify when it's next deployed to WMF that'd be great.

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

Is this bug yet another example of how bug 30716 would be a good thing?

(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.

haakonn wrote:

Confirming that it now works for me, thank you very much.