[tor-relays] Re: Accelerated depreciation of older versions?

Mailing Lists tor-relays
1

Noticed the same thing. On my last server update, there was no updates available. Then two days ago I noticed that the version had jumped by two versions. I updated to 0.4.8.20 two days ago and now it tells me it’s outdated. Version 0.4.8.21 doesn’t even show up on my Almalinux servers for me to update.

Obviously I’m hoping this is due to glitch somewhere because I’m not going to update my servers every few days unless there’s a serious security issue with 0.4.8.20

···

On 11/18/2025 8:31 PM, Nick Weaver via tor-relays wrote:

Was there an explicit decision made or an announcement about more rapid deprecating older server versions with the "Not recommended" flag?

My test relay (tor.icsi-berkeley.org [<http://tor.icsi-berkeley.org/>](http://tor.icsi-berkeley.org/), I use it as my own guard on some tests) was running 0.4.8.18, and I noticed today that it had gained the "Not Recommended" flag which meant my client(s) would not connect to it as the choice of guard.

I updated to 0.4.8.20 (as 0.4.8.21, although technically available, wasn't announced or linked to at the time on the Tor website).  It lost the "not recommended" flag but regained it again as the current consensus now only has 0.4.8.21 and 0.4.9.3-alpha as acceptable versions.

(so, well, update again)?

Was this a deliberate decision or in response to a problem patched in 0.4.8.21 (and not announced as high enough severity to require immediate updating?)  Is this going to be a policy going forward that relays should be updated within <12 hours of patch announcement?

(also, tor26 basically likes everything BUT 0.4.8.21 because that hasn't gotten added to it, I think the Tor network might be disrupted if there is no agreement at all between the 3 authorities selecting recommended version, I think there could be a situation where there is no consensus on "recommended versions" if this isn't fixed)

As of time of writing, from [https://consensus-health.torproject.org/](https://consensus-health.torproject.org/)

moria1 client-versions 0.4.8.19, 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha
moria1 server-versions 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha

tor26 client-versions 0.4.8.4, 0.4.8.5, 0.4.8.6, 0.4.8.7, 0.4.8.8, 0.4.8.9, 0.4.8.10, 0.4.8.11, 0.4.8.12, 0.4.8.13, 0.4.8.14, 0.4.8.15, 0.4.8.16, 0.4.8.17, 0.4.8.18, 0.4.8.19, 0.4.9.1-alpha, 0.4.9.2-alpha, 0.4.9.3-alpha, (Strikethrough: 0.4.8.20, 0.4.8.21 )

tor26 server-versions 0.4.8.4, 0.4.8.5, 0.4.8.6, 0.4.8.7, 0.4.8.8, 0.4.8.9, 0.4.8.10, 0.4.8.11, 0.4.8.12, 0.4.8.13, 0.4.8.14, 0.4.8.15, 0.4.8.16, 0.4.8.17, 0.4.8.18, 0.4.8.19, 0.4.9.1-alpha, 0.4.9.2-alpha, 0.4.9.3-alpha,  (Strikethrough: 0.4.8.21 )

gabelmoo client-versions 0.4.8.19, 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha

gabelmoo server-versions 0.4.8.21, 0.4.9.3-alpha

consensus client-versions 0.4.8.19, 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha
server-versions 0.4.8.21, 0.4.9.3-alpha

-Nick

_______________________________________________
tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org)
To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)
2

Understood. I guess my point is that servers shouldn’t be flagged when the new version is one day old. If it’s a serious security issue, then I expect to see some sort of an announcement on this mailing list because I may go for weeks and never look at my flags on the web. The original email in this thread was the only reason realized it. If I see the average Network traffic that I expect, I simply move on and update my servers once a month.

···

On 11/19/2025 4:03 AM, Marco Moock wrote:

Am 19.11.2025 um 03:06:18 Uhr schrieb Chris Enkidu-6 via tor-relays:


Version 0.4.8.21 doesn't even show up on my Almalinux
servers for me to update.


I assume because it is not in their repo yet. The release way yesterday
night.
3

I’ve noticed the same. The challenge I have is that the Fedora packages are updated several days after the official release. So that makes it difficult to stay current with security updates, unless I want to venture out and start compiling them (which I’d prefer not to).

For example, tor-0.4.8.20 was announced on November 11, yet the rpm didn’t get uploaded until November 15.

Announcement: https://forum.torproject.org/t/stable-release-0-4-8-20/20781
Fedora repo: https://rpm.torproject.org/fedora/43/x86_64/

···

On Wed, Nov 19, 2025 at 1:39 AM Chris Enkidu-6 via tor-relays <tor-relays@lists.torproject.org> wrote:

Understood. I guess my point is that servers shouldn’t be flagged when the new version is one day old. If it’s a serious security issue, then I expect to see some sort of an announcement on this mailing list because I may go for weeks and never look at my flags on the web. The original email in this thread was the only reason realized it. If I see the average Network traffic that I expect, I simply move on and update my servers once a month.

On 11/19/2025 4:03 AM, Marco Moock wrote:

Am 19.11.2025 um 03:06:18 Uhr schrieb Chris Enkidu-6 via tor-relays:


Version 0.4.8.21 doesn't even show up on my Almalinux
servers for me to update.


I assume because it is not in their repo yet. The release way yesterday
night.

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

4

Hi there,

I've noticed the same. The challenge I have is that the Fedora packages are updated several days after the official release. So that makes it difficult to stay current with security updates, unless I want to venture out and start compiling them (which I'd prefer not to).

For example, tor-0.4.8.20 was announced on November 11, yet the rpm didn't get uploaded until November 15.

Announcement: Stable release 0.4.8.20
Fedora repo: Index of /fedora/43/x86_64

Understood. I guess my point is that servers shouldn't be flagged when the new version is one day old. If it's a serious security issue, then I expect to see some sort of an announcement on this mailing list because I may go for weeks and never look at my flags on the web. The original email in this thread was the only reason realized it. If I see the average Network traffic that I expect, I simply move on and update my servers once a month.

I'm one of the people responsible for flagging old versions as a
dirauth operator. Please do not treat this flagging as anything
more than a friendly nudge to update. If there are more serious
issues or the version is so outdated that it isn't maintained
anymore at all, we can exclude the relays from the consensus as a
more drastic measure.

Ideally, your distribution updates quickly, you notice that
automatically, and then apply the update soon.

Cheers
Sebastian

···

On 19. Nov 2025, at 10:50, Matt Connor via tor-relays <tor-relays@lists.torproject.org> wrote:
On Wed, Nov 19, 2025 at 1:39 AM Chris Enkidu-6 via tor-relays <tor-relays@lists.torproject.org> wrote:

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

5

Hi Nick,

I'm one of the people responsible for flagging old versions as a
dirauth operator. Please do not treat this flagging as anything
more than a friendly nudge to update. If there are more serious
issues or the version is so outdated that it isn't maintained
anymore at all, we can exclude the relays from the consensus as a
more drastic measure.

Ideally, your distribution updates quickly, you notice that
automatically, and then apply the update soon.

Except the problem: When you flag an old version then the client appears to no longer accept it as a guard node (it is how I noticed).

By doing so, within <24 hours of new version release, you are eliminating >1/2+ of the potential guard nodes in the network. It is not a "polite nudge", but something that potentially disrupts the network.

If this were true, I would be concerned, but it is not according to my
testing. My Tor Browser happily continues using a guard which has not
yet updated to the latest version.

I'm too lazy to trace the Tor source code (I have a moral obligation not to try to read too much ugly C that wants to be C++ and has >2500 GOTO statements), but I use my relay as a pinned guard for a test-server (with an override so it accepts just a single guard for a hidden service).

My experiment above didn't consider non-standard configurations, but,
as far as I can tell, you're seeing something else. A quick grep through
the source code also doesn't appear to indicate differently.

When the node gets the "Not recommended" flag, it is no longer considered usable as a guard and I get a continuous stream of:

The proper way to implement that would be by just not assigning the
guard flag to the offending relays, which isn't done.

Nov 14 17:44:21.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit.

errors in the log.

There probably needs to be a stated policy on "Absent a security vulnerability of severity X, older server versions are not deprecated for Y days" to prevent this from potentially disrupting the network.

I currently do not see any need for such a policy and will, for the time
being, continue to follow the suggestions of the network team for
version recommendations.

Cheers
Sebastian

···

On 19. Nov 2025, at 18:00, Nick Weaver <nweaver@gmail.com> wrote:

On Nov 19, 2025, at 7:31 AM, Sebastian Hahn via tor-relays <tor-relays@lists.torproject.org> wrote:

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

6

I built an RPM for my Almalinux machine from the v0.4.8.21 source tarball, using the spec file from Fedoa Koji's tor-0.4.8.20-1.el9 source RPM. Looking today, I see they already have v0.4.8.21 RPMs available.

···

On 11/19/25 02:06, Chris Enkidu-6 via tor-relays wrote:

Noticed the same thing. On my last server update, there was no updates available. Then two days ago I noticed that the version had jumped by two versions. I updated to 0.4.8.20 two days ago and now it tells me it's outdated. Version 0.4.8.21 doesn't even show up on my Almalinux servers for me to update.

--

-John (JohnDThompson@gmail.com)
  Appleton, WI USA
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

7

Why is any other than the latest version recommended?

More than one recommended version means that they are all equally good to use.

···

Am Mi., 19. Nov. 2025 um 21:00 Uhr schrieb Sebastian Hahn via tor-relays <tor-relays@lists.torproject.org>:

Hi Nick,

On 19. Nov 2025, at 18:00, Nick Weaver <nweaver@gmail.com> wrote:

On Nov 19, 2025, at 7:31 AM, Sebastian Hahn via tor-relays <tor-relays@lists.torproject.org> wrote:

I’m one of the people responsible for flagging old versions as a
dirauth operator. Please do not treat this flagging as anything
more than a friendly nudge to update. If there are more serious
issues or the version is so outdated that it isn’t maintained
anymore at all, we can exclude the relays from the consensus as a
more drastic measure.

Ideally, your distribution updates quickly, you notice that
automatically, and then apply the update soon.

Except the problem: When you flag an old version then the client appears to no longer accept it as a guard node (it is how I noticed).

By doing so, within <24 hours of new version release, you are eliminating >1/2+ of the potential guard nodes in the network. It is not a “polite nudge”, but something that potentially disrupts the network.

If this were true, I would be concerned, but it is not according to my
testing. My Tor Browser happily continues using a guard which has not
yet updated to the latest version.

I’m too lazy to trace the Tor source code (I have a moral obligation not to try to read too much ugly C that wants to be C++ and has >2500 GOTO statements), but I use my relay as a pinned guard for a test-server (with an override so it accepts just a single guard for a hidden service).

My experiment above didn’t consider non-standard configurations, but,
as far as I can tell, you’re seeing something else. A quick grep through
the source code also doesn’t appear to indicate differently.

When the node gets the “Not recommended” flag, it is no longer considered usable as a guard and I get a continuous stream of:

The proper way to implement that would be by just not assigning the
guard flag to the offending relays, which isn’t done.

Nov 14 17:44:21.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit.

errors in the log.

There probably needs to be a stated policy on “Absent a security vulnerability of severity X, older server versions are not deprecated for Y days” to prevent this from potentially disrupting the network.

I currently do not see any need for such a policy and will, for the time
being, continue to follow the suggestions of the network team for
version recommendations.

Cheers
Sebastian

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

8

Well, friendly nudge or not, the lesson I learned from all the messages in this thread is that the flag is pretty much useless. The problem with flagging servers for absolutely no good reason is that people will start ignoring them and the next time something really serious comes up, people will simply treat it as just another useless flag.

For the time being version .21 isn’t even available on https://rpm.torproject.org/centos/9/x86_64/ and frankly even it were, I wouldn’t be upgrading outside my usual scheduled update unless it were a fix for a serious security vulnerability. So I’ll check that flag some time in mid December and version .20 will have to do for now.

Cheers.

···

On 11/19/2025 10:53 PM, Tor Relays via tor-relays wrote:

Why is any other than the latest version recommended?

More than one recommended version means that they are all equally good to use.

Am Mi., 19. Nov. 2025 um 21:00 Uhr schrieb Sebastian Hahn via tor-relays <tor-relays@lists.torproject.org>:

Hi Nick,

On 19. Nov 2025, at 18:00, Nick Weaver <nweaver@gmail.com> wrote:

On Nov 19, 2025, at 7:31 AM, Sebastian Hahn via tor-relays <tor-relays@lists.torproject.org> wrote:

I’m one of the people responsible for flagging old versions as a
dirauth operator. Please do not treat this flagging as anything
more than a friendly nudge to update. If there are more serious
issues or the version is so outdated that it isn’t maintained
anymore at all, we can exclude the relays from the consensus as a
more drastic measure.

Ideally, your distribution updates quickly, you notice that
automatically, and then apply the update soon.

Except the problem: When you flag an old version then the client appears to no longer accept it as a guard node (it is how I noticed).

By doing so, within <24 hours of new version release, you are eliminating >1/2+ of the potential guard nodes in the network. It is not a “polite nudge”, but something that potentially disrupts the network.

If this were true, I would be concerned, but it is not according to my
testing. My Tor Browser happily continues using a guard which has not
yet updated to the latest version.

I’m too lazy to trace the Tor source code (I have a moral obligation not to try to read too much ugly C that wants to be C++ and has >2500 GOTO statements), but I use my relay as a pinned guard for a test-server (with an override so it accepts just a single guard for a hidden service).

My experiment above didn’t consider non-standard configurations, but,
as far as I can tell, you’re seeing something else. A quick grep through
the source code also doesn’t appear to indicate differently.

When the node gets the “Not recommended” flag, it is no longer considered usable as a guard and I get a continuous stream of:

The proper way to implement that would be by just not assigning the
guard flag to the offending relays, which isn’t done.

Nov 14 17:44:21.000 [notice] Failed to find node for hop #1 of our path. Discarding this circuit.

errors in the log.

There probably needs to be a stated policy on “Absent a security vulnerability of severity X, older server versions are not deprecated for Y days” to prevent this from potentially disrupting the network.

I currently do not see any need for such a policy and will, for the time
being, continue to follow the suggestions of the network team for
version recommendations.

Cheers
Sebastian

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

_______________________________________________
tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org)
To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)