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.
The "oldstable" description [1]:
Note that old stable are there to allow a transition period to the new stable
and generally not to be used for general use.
somewhat matches what ahf described ("During this time, we can hint to them at
upgrading. Some of the reasons for upgrading are new features, safety, and security
issues.")
to some degree.
b) Scope
I would also suggest to add scope information to the support policy to make the
scope/roles of the policy clear (clients, onion services, relays, bridges, dir
auths, ...)
because the current version includes wording that would suggest that it is only about
relays by using terms like "the directory authorities might reject them from the
consensus"
because clients are not in the consensus.
A pointer for arti's support policy would be good if it is not on the same page.
c) document non-mutual expectations
If the torproject expects relay operators to support tor client versions for a
longer period of time
than the torproject it self supports them, then make that clear in the
expectations for relay operators document [3] by pointing to [2].
An updated version of [2] could help relay operators find out the specific date
until when they must support a specific tor series.
Currently it does not include such information (for example the 2026-09-01 date
for 0.4.8.x).
Without explicit information many will believe it is fine to drop support as
soon as the torproject declares them unsupported.
It is probably confusing for relay operators if they get removed from the tor
network for using a end-of-life tor version
while also getting removed from the tor network for NOT supporting EOL version
clients.
3) more proactive communications / announcements
On 2026-04-13 I asked about the EOL date [10] and suggested a blog post
announcement, no reaction to the email was observed before the EOL date on
2026-06-01
but I noticed related gitlab activity after that email.
On my side:
- I will start proactive information for similar relayor changes but they were
very rare in the past (1x in 10 years?).
- I might create a support policy for relayor - blocked until the torproject
support policy changes are completed.
- I'll announce similar changes on my mastodon feed before they take place and
are released.
kind regards,
nusenu
Some pointers to policies/documents, feel free to add more if you notice any
relevant page missing:
[1]
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SupportPolicy
[2]
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleases
[3]
https://community.torproject.org/policies/relays/expectations-for-relay-operators/
[4]
https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Relay-EOL-policy
[5]
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/ReleasePolicy
[6] https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/TROVE
[7]
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/DeprecationTorPhases
[8] https://community.torproject.org/policies/dir-auth/recommended_versions/
[9] https://gitlab.torproject.org/tpo/network-health/team/-/work_items/149
[10]
https://lists.torproject.org/mailman3/hyperkitty/list/[email protected]/message/JVESK2XTDNPTQQOGQWQG3RYGD5IDT5OF/
https://gitlab.torproject.org/tpo/network-health/team/-/work_items/460#note_3424853
--
https://nusenu.github.io
_______________________________________________
tor-relays mailing list -- [email protected]
To unsubscribe send an email to [email protected]
