[tor-talk] Possibly Smart, Possibly Stupid, Idea Regarding Tor & Linux Distributions

I will admit that I have not fully thought this through yet, so I am writing this in the hope that other folk will follow up, share their experiences and thoughts. So: I have installed a bunch of Tor systems in the past few months - CentOS, Ubuntu, Raspbian, Debian, OSX-via-Homebrew - and my abiding impression of the process is one of "friction". Before getting down to details, I hate to have to cite this but I have been a coder and paid Unix sysadmin on/off since 1988, and I have worked on machines with "five nines" SLAs, and occasionally on boxes with uptimes of more than three years; have also built datacentres for Telcos, ISPs and built/setup dynamic provisioning solutions for huge cluster computing. The reason I mention this is not to brag, but to forestall * "There is nothing hard about tar-xvf/configure/make/make-install", or... * "All you need is {yum,apt-get} and to add $MAGIC_REPOSITORY (eg: backports) to $WEIRD_FILE", or... * "All you need is launch $NICHE_DISTRO_GUI_TOOL and tick $SOMEBOX under $FOLDED_MENU_ITEM" * "Read the manual for 'dpkg'" / "what about reproducible builds?" / "Install OpenBSD" ...responses. I know that such tools exist, I know how to drive them; however I am not "normal", and I suspect the same can be said of anyone who would offer such advice to a new person who wants to use Tor. If I have not messed this up, the current state of the Tor "defaultinstalliverse" includes: Debian Jessie: 0.2.5.12-4 Raspbian Jessie - tracks Debian (this is the Raspberry Pi platform) Ubuntu Xenial LTS 0.2.7.6-1ubuntu1 Ubuntu Yakkety 0.2.8.8-1ubuntu1 Centos7(1611) - n/a, use Fedora Fedora 0.2.8.12-1.fc26 OSX Homebrew 0.2.9.8 OSX Macports 0.2.9.8 There's quite a spread here; amazingly the OSX repos are on the cutting edge, with Fedora and the latest Ubuntu is close behind. Where I feel that issues arise are in the older Ubuntus and Debians. Again, I understand that there are "backports" repos, but my experience of encouraging new people to adopt Tor is one of trying to help them to jump over the hurdles which we immediately place in their way. The conversation usually goes a bit like this: "Okay, you want to install Tor. First thing: you must ignore the version of Tor that your operating system supplies. Oh, wait, you already installed it? Did you use backports? You don't know what that is? Okay, if you type 'tor' what numbers does it give you? Type "which tor". Yes, that one. Okay, that's an old version, we need to remove that and give you something better. You don't know how to remove it because you were using the GUI?" ...which does not constitute a "positive user experience", nor "simple advice", nor is it "fun". It's gotten to the point where sometimes, if I want to ensure that the user has a current Tor daemon on their machine to play with, I tell them to install Tor Browser Bundle and use the SOCKS port to connect to Tor, a solution which will go away once UNIX socketing is adopted for TBB communications. So this is kinda the problem statement: - old versions of Tor are out there in the wild - they pollute the software environment, representing "cognitive load" / barriers to easy adoption and learning - adoption and learning are critical to the growth in use of Tor Further, as additional context, I am told that Tor "support" models will be changing soon, and that only $SOME_NUMBER of recent releases will retain support/bugfixes; presumably if one does not get on the train and track the supported releases, one will be on one's own. Given the (less than corporate-sized) resources at Tor's disposal, I think this is fair and agree with the decision. I do not have a magic fix to address the problem statement, but I do have some observations: 1) change always needs to be paid for; if we glibly say "someone at Tor should build releases and push them to the repos!" then that person will have to be paid for, and from where does the money come? This challenge straddles growth, usability and outreach. 2) the repos won't always appreciate people throwing new code at them, and even if that happens they may relegate it to a $MAGIC_REPOSITORY to a net loss in usability as mentioned above. 3) There is a very big event impending, the freeze for "Debian Stretch"; from the above you can see that Debian is possibly the most significant source of "install pollution" of Tor; it impacts all debian-derived distros, and even Ubuntu "LTS" (the current Long Term Support release) seems to treat Tor with some drag even though Ubuntu has "rolled its own". I am told that Debian prioritises code stability - and as a former Solaris engineer I wholeheartedly agree with that goal - but where Tor is security-sensitive software with a bullseye target painted on its forehead, perhaps it'd be wiser for the per-platform communities to plan to move faster. Observing the "installiverse" list, we can see that it is not considered a fatal flaw that (say) Centos does not distribute Tor; documentation on the Tor website says that Centos users should use the Fedora packages. On that basis one possible step towards reducing install friction might be to request that Debian wholly remove Tor from "Stretch", recommending instead the binaries which Tor provides at https://www.torproject.org/docs/debian.html.en - Tor possibly taking on-board Raspbian builds as mentioned on that page. (but see point 1 re: cost) Indeed, reviewing https://www.torproject.org/docs/debian.html.en provides quite a nice thumbnail sketch of the "if-and-or-but" decisions which new users face in adoption: ---- begin ---- If you're using Debian, just run "apt-get install tor as root. Note that this might not always give you the latest stable Tor version, but [...]. To make sure that you're running the latest stable version of Tor, see option two below. Now Tor is installed and running. Move on to step two of the "Tor on Linux/Unix" instructions. Option two: Tor on Ubuntu or Debian Do not use the packages in Ubuntu's universe. In the past they have not reliably been updated. That means you could be missing stability and security fixes. Raspbian is not Debian. These packages will be confusingly broken for Raspbian users, since Raspbian called their architecture armhf but Debian already has an armhf. See this post for details. You'll need to set up our package repository before you can fetch Tor. First, you need to figure out the name of your distribution. A quick command to run is lsb_release -c or cat /etc/debian_version. If in doubt about your Debian version, check the Debian website. For Ubuntu, ask Wikipedia. ---- end ---- Please note: none of this is to criticise the (I am absolutely certain) heroic work which has been required to get Tor into the hands of potential users to date; all projects go through these growing pains, and in no way am I trying to point fingers, apportion blame, nor attempting to suggest that anything has been done wrongly. But what I would like to do is see the above complexity ("ask Wikipedia?") be simplified into coherent nonexistence, for all major platforms. My (personal, subjective) ideal end-state is when someone asks me how to set up a Tor daemon I can confidently say: "Go to the Tor website, Follow the instructions, you will have to poke some menus for whatever OS you are using, and then paste a couple of lines of code, and that's it." My _ideal_ end-game would further have "tor" bundling "torsocks" - a tool which will become more critical for server-side adoption, real soon now - as well as some CLI "tor setup wizards" But I am happy to park those in favour of the next generation of Debian users, still installing Stretch in the year 2019* to not still be stuck with Tor 0.2.9 when, by that time, we should be on... 0.3.2 ? Comments? - alec * which is when I am guessing "Debian Buster" will freeze? https://wiki.debian.org/DebianBuster -- http://dropsafe.crypticide.com/aboutalecm