[tor-dev] v2 Onions, IPv6 BiDir P2P Capability Regression... [re: Relays running unsupported EOL ver]

[grarpamp]

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 at 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-policy