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.
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 To unsubscribe send an email to tor-relays-leave@lists.torproject.org