Accelerated depreciation of older versions?
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/>, 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/ 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
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/>, 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/
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 To unsubscribe send an email to tor-relays-leave@lists.torproject.org
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. -- Gruß Marco Send unsolicited bulk mail to 1763517978muell@cartoonies.org
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.
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
Hi there,
On 19. Nov 2025, at 10:50, Matt Connor via tor-relays <tor-relays@lists.torproject.org> wrote:
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.
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 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. 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). When the node gets the "Not recommended" flag, it is no longer considered usable as a guard and I get a continuous stream of: 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.
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
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
Am 20.11.2025 um 04:53:15 Uhr schrieb Tor Relays via tor-relays:
Why is any other than the latest version recommended? More than one recommended version means that they are all equally good to use.
Various Linux distributions (and maybe some BSD too) have a release policy that makes them release only versions that fix serious issues, like security-related bugs. Debian is such an example, it still has 4.8.16 https://tracker.debian.org/pkg/tor -- Gruß Marco Send unsolicited bulk mail to 1763610795muell@cartoonies.org
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 <mailto:tor-relays@lists.torproject.org>>:
Hi Nick,
> On 19. Nov 2025, at 18:00, Nick Weaver <nweaver@gmail.com <mailto:nweaver@gmail.com>> wrote: >> On Nov 19, 2025, at 7:31 AM, Sebastian Hahn via tor-relays <tor-relays@lists.torproject.org <mailto: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 <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>
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
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.
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. https://koji.fedoraproject.org/koji/packageinfo?packageID=4002 -- -John (JohnDThompson@gmail.com) Appleton, WI USA
Hello! Nick Weaver via tor-relays:
Was there an explicit decision made or an announcement about more rapid deprecating older server versions with the "Not recommended" flag?
There is no more rapidly deprecating older server versions per se, no. The issues fixed in both 0.4.8.20 and 0.4.8.21 were deemed serious enough to un-recommend previous Tor versions (as far as running them on relays is the concern).
My test relay (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.
FWIW that's not really a flag Tor is dealing with. It's just something that is generated by relay-search to give additional information to relay operators. I don't think your client(s) take that "flag" into account when picking Guards.
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)?
Yes, please.
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?
It depends on the severity of the bugs which get fixed in releases. Generally speaking, I'd see the 0.4.8.20 and 0.4.8.21 releases more as an exception than the new norm. There are no plans of speeding up the deprecation of older Tor versions.
(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)
I don't think this is as severe as you might imagine. As the spec says `server-versions` contains "Recommended Tor server software". It's not a MUST as you can see consensuses are still built and including a load of relays not having upgraded yet.
As of time of writing, from 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
Georg
participants (8)
-
Chris Enkidu-6 -
Georg Koppen -
John Thompson -
Marco Moock -
Matt Connor -
Nick Weaver -
Sebastian Hahn -
Tor Relays