On Fri, 06 Sep 2019 02:20:00 +0000 Mike Perry mikeperry@torproject.org wrote:
- "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?
Nothing, perhaps. It's just a matter of dealing with an external repo itself: adding it, ensuring it is added on all new machines, ensuring the distro specifier is update on distro upgrades, and likely working on integrating all of that that into a centralized deployment system (not ansible): e.g. do I add that into sources.list directly, or put a file into sources.list.d, if a file, then will it be a file directly, or symlinked from the location into which all other configs are rsync'ed to the machine, etc.
Considering the previously perceived low benefit of running the very latest version in the first place, or the benefit of running that over backports (the Tor repo might have only a marginally newer version than backports), it should be easy to see why the desire to skip all of the above.
(For backports it is the same "overhead", but I am likely adding backports anyway, due to wanting something else from it, not just Tor).
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?
Personally I do not use ansible and would not prefer that to be made the only way to do something.
Where does the security weakpoint risk come from? Does apt-transport-tor/onion service repository availability help in your mind here?
As with adding any third-party repository, it means trusting the repository provider to install and run any root-privilege code on the machine. In case the repository server (or actually the release process, including signing) is compromised, on the next update it can serve malicious or backdoored versions of the software. So naturally from the security standpoint it is beneficial to add (and trust) as few repositories as possible, just to reduce the "attack surface".