Roman Mamedov:
On Thu, 05 Sep 2019 02:11:00 +0000 Mike Perry mikeperry@torproject.org wrote:
- "I didn't know that Debian's backports repo has latest-stable Tor!"
I only looked to backports when I get a warning on the metrics website that my versions are not recommended. Aside from that, I thought that running LTS on relays is actually beneficial, to prevent any newly introduced bugs in the current latest versions from having an impact on the network infrastructure.
We are moving towards relying on CI for finding functional bugs, and code review and static analysis for security issues.
I don't believe that current LTS periods of time will necessarily provide better results for either of these classes of risk than investing in better CI and in other forms of diversity than just release version.
However, I could see a middle ground where we shorten LTS timescales for the relay side, but don't eliminate them, as we work towards where we want to be with CI and security issue risk reduction (or other forms of diversity).
- "I didn't see the Tor Project repos mentioned in Tor's Relay docs!"
I was using them in the past, but then decided not to, as it's adding some management overhead and also one more potential security weakpoint.
These two strike me as being likely to be very high on the list of common reasons, when the choice is deliberately made.
What can we do to reduce management overhead?
Right now, there are quite a lot of separate pages pointing to different pieces of the steps of adding our repo. Is that the problematic piece? Are there additional things make it more of a hassle than it should be?
Someone else mentioned ansible. Would an ansible playbook that add our repositories and their gpg keys make this easier? Or is it better just to keep the steps all on a single page?
Where does the security weakpoint risk come from? Does apt-transport-tor/onion service repository availability help in your mind here?