v2 Onions, IPv6 BiDir P2P Capability Regression... [re: Relays running unsupported EOL ver]
On that, and regardless of what TPO Inc says re... tor is a bit decentralized, and freely licensed, as such... DirAuths, HSDirs, Relays are all free to choose to continue signing over and running older versions in order to support the community of tor clients that are happily using useful features that the Tor Project on its high horse demands with its blanket fiat fist and refusing to consider and support users... to remove from such users, herein as noted before, v2 onions and simple OnionCat IPv6 /48+80 UDP transport P2P E2E BiDir addressing and thus all current IPv6 capable apps incl VOIP Bittorrent comms status chat game coins etc and future apps that needing such tech to operate across onionland. That's bad, and a big regression in service, both active now, and preventing potential development on interesting new uses and applications in the future. These users, these features, apps, and their recognized tradeoffs, their free choices made therein, are of merit and import. And Tor Project is choosing to censor and ban v2 and them without regard. Perhaps some v2 users will likewise email all the relays seeking not their censorship, but instead their support. But perhaps due to any needs they may have to remain unknown they may not be able to voice out to lists etc, as such the surfaceweb cannot make dis-use assumptions and must indeed hold v2 in their stead for them. Kudos to those distributed DirAuths, HSDirs, and Relays who refuse to comply with Tor Project Inc demands to crush all v2 onion users and their legitimate use cases. The better path is for TPO to either recognize and continue, or to modularize v2 onion support out to community stewardship such that the features that it provides may continue until a future vN or a seamless scalable externally attached solution for the same features and uses is found. And to make v3 the default choice "advertised" in docs and configs, with v2 a lesser noted option yet for just providing above capabilities. Tor Project still doesn't have a version feature matrix table, nor an honest open balanced and free to all authors wiki education page detailing use case and tradeoff notes for users about the v2+OnionCat vs v3 tech capabilities, thereby allowing tor users to freely make educated choices therein on their own. Instead it has a bricked up and censored prop blog and lists. Like TPO's censorship, that's unfair, unwarranted, questionable, and needs to end. ps: Yes, upgrade, if merely behind on versions sake, lots of good fixes, improvements, performance, features, security, etc come with those. But when it comes to a big and permanent regression of overall network capability issue such as this, that's different, and needs consideration beyond the vague handwavy universal whitewash "reason" being uttered by TPO such as "v2 insecure"... which is false re educated tradeoffs and uses that users are free to evaluate and choose on their own. In fact, users are in better more intelligent aware position having learned a bit of something and made that themselves. Users are also free to eval by bring forward to today sense of the NSA's 10+ year old slides that noted "Tor Stinks". What conditions, designs, capabilities, etc have changed since then. Cheers all. On 10/5/21, Georg Koppen <gk@torproject.org> wrote:
Relays running unsupported Tor versions is a problem we have never really dealt with in a systematic way in the way. Some of you might recall that we (with the help of volunteers) tried back in 2019/2020 to get operators, running an unsupported Tor version, to upgrade[1] but then we dropped the ball. Alas.
We just started that process again by contacting every relay operator running an outdated Tor version (any version not 0.3.5.x or 0.4.5.x or 0.4.6.x or 0.4.7.x) by email where possible. Additionally, we created a wiki page outlining the current process and things we still need to figure out.[2] On that page we plan to make statistics related to the EOL relay removal available as well, including the final list of relays we'll reject. Thus, stay tuned. Feedback, as always, is very much welcome!
We plan to keep this topic on our radar this time while refining the process as we go. Meanwhile, if you are running a relay with an unsupported Tor version, please upgrade for the sake of our users' safety.
If you need help, join us on #tor-relays or #tor-relays:matrix.org if you use Element.
[1] https://blog.torproject.org/removing-end-life-relays-network [2] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Relay-EOL-poli...
Hello, I never used Onioncat before
Well to know about it, go download compile and run it, or get it from your OS ports/packages, try it out, play with it, see how it works. It's fun and very useful for running applications across onionland... and there's a lot more apps uses and protocols and services in the world to discover and create than just boring UniDirectional Https Webservers :) https://www.onioncat.org/ What's not fun, is that as you can see from the original message, the Tor Project censors and bans all talk of this from their talk and relay lists... they are hypocrites, and are hiding things from their users, operators, and funders. They censor all sorts of messages for no good reason for many years now. This is very bad. For an org that claims to support Free Speech, this is a very big suspicious incriminating problem.
but on the website it says it is compatible with v3... can you explain me what is not compatible with v3?
v2 uses 80-bit addressing, this fits perfectly 1:1 inside IPv6 128-bit addressing RFC 48 + tor 80 = IPv6 128 v3 is far wider than v2's 80-bit, and just like i2p it cannot be represented inside IPv6's 128-bits, thus 1:1 breaks, and a lot of things get messy and apps start having limitations. OnionCat website says it's v3 compatible because you can physically by hand hardcode bidirectional IPv6 <--> v3 mappings into onioncat config. But that method obviously does not scale to P2P sized applications which can grow to many thousands of users needing to communicate at random on the fly. Among other technical problems. Bittorrent and other IPv6 enabled apps work as they should with zero user config needed in v2+onioncat onionland today, but not with v3+onioncat. Boring webservers, yes they work under v3+onioncat but not more exotic apps that need P2P / BiDir / IPv6 / UDP support. You will have to try onioncat with v2 and v3, and - compare how ping6 works in the different direction modes - compare how transmission-bt + opentracker works to begin to understand why Tor Project censoring v2 is a major problem both today, and totally forecloses on an entire class of potential future apps tomorrow. There is no legitimate reason for Tor Project Inc to shutdown the v2 onion network. And the "security risk" TPI likes to throw out, well that is obviously 100% entirely up to decision of each user and app userbase to make for themselves to consider trading that off against their app use case need, absolutely not for Tor Project Inc and its authoritarians to dictate to the user. There are even more big problems with tor, and Tor Project Inc censors those too, but you can search for them... "Tor Stinks -- NSA"
participants (1)
-
grarpamp