Hi Steve!

Nadas, Stephen:

Hi Georg,

Do you have a more specific timeframe than "we will soon"?

I ask because currently there are ongoing discussions with the interested user as to how best to replace the hardware that runs this relay. Everything being equal we would wait for the new solution and then change the software. But will take some time (weeks easily) so if we have an idea what you are thinking that would be helpful for us to plan.

I don't have an exact date for you. Here is what I answered another operator asking essentially the same questions:

""" It's not exactly set yet. We want to make the change in Tor's 0.4.4 timeframe.[1] And the feature freeze of it is scheduled for May 2020 with backports of the delisting patch for stable versions, so Directory Authorities can start applying it. So, I'd say while not a matter of days it's a matter of some weeks which is why we start contacting operators now. """

Hope this helps, Georg

[1] https://trac.torproject.org/projects/tor/ticket/32672

Thanks, Steve

-----Original Message----- From: support-bounces@cs-mailman.bu.edu support-bounces@cs-mailman.bu.edu On Behalf Of Georg Koppen Sent: Tuesday, February 25, 2020 7:36 AM To: tor@cs.bu.edu Cc: Network Health network-health@lists.torproject.org Subject: Please upgrade your "BostonUCompSci" Tor relay running 0.2.9.17

Hi,

You are running a Tor relay, which is great:

http://rougmnvswfsmd4dq.onion/rs.html#search/94C4B7B8C50C86A92B6A20107539EE2...

But that Tor version is obsolete, and because of old bugs, we will soon cut relays running those versions out of the network. Please consider upgrading!

You can find Tor packages and instructions for your distro / OS here: https://community.torproject.org/relay/setup/guard/

Ideally you will switch to keeping up with our stable releases, but if you need a stable that is especially stable, the Tor 0.3.5 branch will be maintained until Feb 2022:

https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorR...

and you can see the lifetimes of other Tor versions on that table too.

Let us know if we can do anything to make the process easier.

And lastly, I am cc'ing the new network health mailing list (which has public archives), to help us stay synced:

https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkHealthTeam

Thanks! Georg

Hi!

Paul Stauffer:

Hi Georg. I was taking a look at this, and the reason our node is still on 0.2.9.17 is because that's still the latest version published in EPEL for CentOS 6. Any plans to push 0.3.5 to EPEL6? As Steve mentioned, we do plan to replace our node's hardware soon, which will involve an OS upgrade to CentOS 7 or 8. But there may be other nodes out there besides ours that are still running CentOS 6, so updating the tor package in EPEL for them would be a quick way to get all of them upgraded.

Related to this, I recall that years ago the Tor Project used to run its own yum repo that got more frequent updates than EPEL (looks like EPEL only gets the LTS versions). We only switched to EPEL when the "official" repo went away. Are there any plans to bring that back, to make it easy to keep nodes updated with all the new releases?

Thanks for asking. Well, on the positive side, we actually have this repository back[1] thanks to a volunteer spending time on the packaging effort. On the flip side, though, CentOS 6 is not supported there (yet) only version 7 and 8. CentOS 6 will be end-of-life later this year and I heard it is sufficiently old that the packaging scripts available for version 7 and 8 need to get bigger changes to have a chance working for CentOS 6 at all. I am not sure whether our volunteer will get to it and whether the effort is actually worth it in this case.

So, I'd assume the "best" path forward for you or anyone else who is stuck on CentOS 6 right now is to compile Tor themselves. We don't have any official documentation for that, though. :( But we could easily put it somewhere on our wiki[2] if someone came up with instructions. :)

I know it's not a great answer but I at least don't have a better one for you at this point, alas...

Georg

[1] https://rpm.torproject.org/ [2] https://trac.torproject.org/projects/tor

best,

• Paul

On Wed, Feb 26, 2020 at 08:51:03AM +0100, Georg Koppen wrote:

...

Hi Steve!

Nadas, Stephen:

...

Hi Georg,

Do you have a more specific timeframe than "we will soon"?

I ask because currently there are ongoing discussions with the interested user as to how best to replace the hardware that runs this relay. Everything being equal we would wait for the new solution and then change the software. But will take some time (weeks easily) so if we have an idea what you are thinking that would be helpful for us to plan.

I don't have an exact date for you. Here is what I answered another operator asking essentially the same questions:

""" It's not exactly set yet. We want to make the change in Tor's 0.4.4 timeframe.[1] And the feature freeze of it is scheduled for May 2020 with backports of the delisting patch for stable versions, so Directory Authorities can start applying it. So, I'd say while not a matter of days it's a matter of some weeks which is why we start contacting operators now. """

Hope this helps, Georg

[1] https://trac.torproject.org/projects/tor/ticket/32672

...

Thanks, Steve

-----Original Message----- From: support-bounces@cs-mailman.bu.edu support-bounces@cs-mailman.bu.edu On Behalf Of Georg Koppen Sent: Tuesday, February 25, 2020 7:36 AM To: tor@cs.bu.edu Cc: Network Health network-health@lists.torproject.org Subject: Please upgrade your "BostonUCompSci" Tor relay running 0.2.9.17

Hi,

You are running a Tor relay, which is great:

http://rougmnvswfsmd4dq.onion/rs.html#search/94C4B7B8C50C86A92B6A20107539EE2...

But that Tor version is obsolete, and because of old bugs, we will soon cut relays running those versions out of the network. Please consider upgrading!

You can find Tor packages and instructions for your distro / OS here: https://community.torproject.org/relay/setup/guard/

Ideally you will switch to keeping up with our stable releases, but if you need a stable that is especially stable, the Tor 0.3.5 branch will be maintained until Feb 2022:

https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorR...

and you can see the lifetimes of other Tor versions on that table too.

Let us know if we can do anything to make the process easier.

And lastly, I am cc'ing the new network health mailing list (which has public archives), to help us stay synced:

https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkHealthTeam

Thanks! Georg

Paul Stauffer:

On Tue, Mar 10, 2020 at 09:27:24AM +0100, Georg Koppen wrote:

...

Thanks for asking. Well, on the positive side, we actually have this repository back[1] thanks to a volunteer spending time on the packaging effort. [1] https://rpm.torproject.org/

Cool, good to know. How much of a commitment is there to maintain that repo? If this volunteer moves on to other things, is it certain that someone else will pick it up? Would you recommend using this repo for guard / exit nodes, to keep up with the latest and greatest features? Or is it better for such nodes to stick with an LTS version for greater stability?

For the maintenance question: it is not a random volunteer that showed up who is maintaining our RPMs but what we call a core member of our project. That means someone being longer involved and better integrated into our community. Sure, there is still the risk that they move on and someone needs to pick this up (again) but right now I am not worried about that scenario. Moreover, we have some interest in maintaining support for RPMs given our network health efforts and the better diversity we get by Tor relays running on CentOS systems and not only on, say, Ubuntu/Debian as far as Linux is concerned.

For using LTS vs. non-LTS: there is no policy yet to recommend one over the other (although there might come one in the nearer future in favor of non-LTS Tor used on relays) but we feel relays should track regular releases, if possible, as we get that way performance and stability improvements etc. faster out which benefits our users. There is the potential flip side here as this could be hurting relay diversity, but overall we think that's worth it. Thus, if you can, please track non-LTS releases.

Georg