Sebastian Hahn via tor-relays:

...

On 1. Jun 2026, at 20:19, nusenu via tor-relays <tor-relays@lists.torproject.org> wrote:

Hi,

relayor v26.2.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v26.2.0

This release marks the end of "MyFamily" support in relayor. Since all supported tor versions support the Happy Family design there is no reason to continue supporting the old "MyFamily" method to declare relay families.

relayor is an ansible role that helps you with automating tor relay operations https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-oper...

Changes since v26.1.0: - remove MyFamily support: The last tor version that required MyFamily (0.4.8.x) in addition to Happy Family support reached end-of-life on 2026-06-01 - use absolute filter name to fix error "No filter named 'ipaddr'"

kind regards, nusenu

Hi nusenu,

I am not a fan of breaking security for clients not running the latest supported release, while those clients continue to work on the network. I have started a discussion among dirauth operators on how to deal with relays who are actively harming outdated clients like that.

I appreciate your eagerness to push forward, but would argue the harm caused by removing MyFamily across the board is greater than keeping it around for some time. There are already network team plans to break compatibility with an update which would actually mean old clients refuse to function, which IMO is much better than breaking security silently.

To add to that: there is a transition process as always when a Tor version goes EOL. We've been done that several times in the past and that should not be anything new. Moreover, as Sebastian indicated, we have this time a hard break for 0.4.8.x clients as well, which is publicly documented in Gitlab[1] and scheduled for 2026-09-01. By then 0.4.8.x relays will likely be blocked from the network as well. Thus, supporting MyFamily until then seems like a good choice to me to avoid at least confusion among relay operators, in particular as we link to your tool and talk about setting up MyFamily in the post-install section of our community portal.[2] I'd suggest you reconsider just pulling the plug. Georg [1] https://gitlab.torproject.org/tpo/network-health/team/-/work_items/460 [2] https://community.torproject.org/relay/setup/post-install/

Hi Sebastian,

I have started a discussion among dirauth operators on how to deal with relays who are actively harming outdated clients like that.

As someone who advocated for many years that the torproject and tor directory authorities should take a stronger stance on relays without proper family configuration I really appreciate if tor directory authorities would finally be more active and take actions against such relays. That would be unexpected and surprising but a very welcome and positive outcome. Please do not limit the removal of relays to just relays putting end-of-life tor clients at risk but **also** include relays that put currently supported tor clients at risk. MyFamily does not support super large groups as you know. To avoid surprising relay operators I would suggest to officially announce that change in actually enforced policy because operators are not used to it since many run relays in their current configuration since a long time and directory authorities never did take any actions against them. I've been in contact with one large operator that would be affected and they confirmed that they will update their configuration soon. In OrNetStats I had(*) a dedicated section for relay groups that have an actual chance to perform end-to-end correlation attacks:

Operators are only listed if they actually have a chance to do end-to-end correlation attacks, that is:

- their guard and exit probability is > 0% - they did not properly configure MyFamily - they run in more than a single /16 network block

(*) unfortunatelly onionoo data quality is still not back to how it used to be before the CollecTor/collector-rs change on 2026-04-02, therefore OrNetStats has not been updated since March 2026 because it depends on collector and onionoo data. kind regards, nusenu -- https://nusenu.github.io

All three of my web tunnels users are dominated by Russian and Iranians This gives a warm glow that I may be doing good I do worry that a malevolent party could set up a webtunnel and identify originating IP addresses since the webtunnel is, this is for these users, the first way into the system? Perhaps webtunnel providers cannot be anonymous Gerry -----Original Message----- From: Georg Koppen via tor-relays <tor-relays@lists.torproject.org> Sent: 08 June 2026 10:07 To: tor-relays@lists.torproject.org Cc: Georg Koppen <gk@torproject.org> Subject: [tor-relays] Re: relayor v26.2.0 is released - Goodbye "MyFamily" Georg Koppen via tor-relays:

Sebastian Hahn via tor-relays:

...

...

On 1. Jun 2026, at 20:19, nusenu via tor-relays <tor- relays@lists.torproject.org> wrote:

Hi,

relayor v26.2.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v26.2.0

This release marks the end of "MyFamily" support in relayor. Since all supported tor versions support the Happy Family design there is no reason to continue supporting the old "MyFamily" method to declare relay families.

relayor is an ansible role that helps you with automating tor relay operations https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor- relay-operator

Changes since v26.1.0: - remove MyFamily support: The last tor version that required MyFamily (0.4.8.x) in addition to Happy Family support reached end- of-life on 2026-06-01 - use absolute filter name to fix error "No filter named 'ipaddr'"

kind regards, nusenu

Hi nusenu,

I am not a fan of breaking security for clients not running the latest supported release, while those clients continue to work on the network. I have started a discussion among dirauth operators on how to deal with relays who are actively harming outdated clients like that.

I appreciate your eagerness to push forward, but would argue the harm caused by removing MyFamily across the board is greater than keeping it around for some time. There are already network team plans to break compatibility with an update which would actually mean old clients refuse to function, which IMO is much better than breaking security silently.

To add to that: there is a transition process as always when a Tor version goes EOL. We've been done that several times in the past and that should not be anything new. Moreover, as Sebastian indicated, we have this time a hard break for 0.4.8.x clients as well, which is publicly documented in Gitlab[1] and scheduled for 2026-09-01. By then 0.4.8.x relays will likely be blocked from the network as well. Thus, supporting MyFamily until then seems like a good choice to me to avoid at least confusion among relay operators, in particular as we link to your tool and talk about setting up MyFamily in the post-install section of our community portal.[2]

I'd suggest you reconsider just pulling the plug.

@nusenu: is there any progress on that? We now had one dir-auth operator, folks from the network and network-health team weighting in and suggesting that your change was well-intentioned but rushed. It would be nice if you could update relayor accordingly. Thanks, Georg

Georg

[1] https://gitlab.torproject.org/tpo/network-health/team/-/work_items/460 [2] https://community.torproject.org/relay/setup/post-install/

_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org

nusenu via tor-relays <tor-relays@lists.torproject.org> wrote:

TLDR: There appears to be a mismatch between the support policy [1] vs. actual expectations from torproject people, it would be beneficial to clarify and update the policy and documentation to avoid similar situations (different expectations and understandings of what EOL means in the context of the torproject) in the future and so we and others can learn from it and hopefully prevent it from happening again.

Shortly after the release and feedback in this thread I added a note to the release information about delaying the upgrade to relayor v26.2.0 if the operator runs relays across more than one /16 IPv4 or /32 IPv6 network.

ahf wrote:

...

When a release goes EOL, we have a period where we can work with other people and partners, who are in contact with us, about their use of Tor. During this time, we can hint to them at upgrading. Some of the reasons for upgrading are new features, safety, and security issues. We are not in a hurry at all here.

It is clear now - after the emails in this thread - that some have expectations that go beyond the end-of-life date of a tor release series.

1) The current support policy does not document the mentioned stages after the EOL date. The current support policy [1] from Jul 19, 2022 describes these stages:

-> alpha -> release candiate (rc) -> stable -> oldstable -> end-of-life

So according to that policy the last event in the lifecycle of a tor release series is the end-of-life date. End-of-life releases are unsupported and "You are on your own.":

[1]:

...

After that, the release will be considered End of Life (EOL) as in unsupported meaning that at any point after that state is set for the release series, the directory authorities might reject them from the consensus.

Most notably [1] and [2] do not say anything about the mentioned additional stages beyond the end-of-life date, in the specific case of 0.4.8 the stage between 2026-06-01 - 2026-09-01 and the stage after 2026-09-01.

2) Clarifying [1] with the mentioned expectations would be beneficial

I also created a gitlab issue for this under: https://gitlab.torproject.org/tpo/core/team/-/work_items/32

a) EOL meaning

Since the term "end-of-life" already has a certain meaning in the software world https://en.wikipedia.org/wiki/Software_release_life_cycle#End-of-life I think it is best do not create a torproject specific meaning of "end-of-life" to avoid similar confusion in the future.

While I support this argument, I wish to point out the hypocrisy of anyone so involved in the Tor Project, which itself violated this policy early on and has continued to do so for over 20 years, now making the argument at this late date. When I first became aware of tor and began to use it, I was confused for some time by its misuse of the term "alpha" releases. From the mid 1960s through the early 1990s, during which time the vast majority of software publicly available was written by hardware vendors, e.g., Burroughs, CDC, DEC, Fujitsu/Facom, Harris, Honeywell, IBM, ICL, NCR. In the customer (a.k.a. "user") communities, beta releases were known, but very few customer sites chose to sign the vendors' contracts for the privilege of being on the bleeding edge of development by being a beta test site. Those that did so, however, were reputed to receive intensive support in analyzing bugs and producing fixes for them. Alpha releases, by contrast, were basically out of view outside the vendor corporations themselves and were basically under tight wraps. It was occasionally possible to get some company representative to admit that alpha releases did exist, but they wouldn't admit to having any information about them except that they were strictly internal to those corpations. Thus, after having always heard the terms used with these understandings, it took me a while to understand that the Tor Project was yet another victim of NIH Syndrome in its own small way. :-) Another example in a much larger way was the CSRG at U.C. Berkeley, who apparently ignored much of the terminology previously invented elsewhere in the development of support for virtual memory systems and instead invented their own. All of the modern BSDs continue to use that vocabulary. One serious, deficiency, IMO, of the CSRG's terminology was the lack of the term "page frame" and the consequent substitution of the word "page", which results in their use of "page" for two different, but very related, concepts. That can lead to a great deal of confusion in some situations. Anyway, yes, please do publish clear definitions for the different phases of the tor project's software support cycle (a.k.a. "life" cycle). Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************