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
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
