Hi,
I've had a look at the branch, and here's a first set of comments
and questions. I'll test an ISO later.
First, congrats, this generally looks very good!
anonym wrote (27 Feb 2014 05:35:18 GMT) :
> It also removes Vidalia.
Why? Last time we discussed this a few months ago, iirc the consensus
was that Vidalia still was the only available controller with some
needed features, such as the network map (e.g. to check if the circuit
isolation settings work correctly).
> sudo -HEu tor-launcher /usr/bin/tor-launcher
It would feel safer to add to env_keep for this command only.
See examples in config/chroot_local-includes/etc/sudoers.d/zzz_upgrade.
Also, probably add -n.
> tor_set_in_torrc () {
> sed -i "/${1}\s/d" "${TOR_RC}"
> tor_append_to_torrc "${1} ${2}"
> }
This would feel safer if the sed regexp was anchored to the beginning
of a line (with ^). Perhaps it's too big a gun for the problem at
hand, but augeas could also be used to do that nicely.
Also, I would add "|| true" at the end of the sed line, so that this
function is safe to use in a "set -e" environment.
Regarding "Install authbind and start Tor with it.": wouldn't it be
a bit safer, and perhaps even simpler, to move the DNSPort to
a non-privileged port, and use iptables/netfilter to redirect DNS
requests to it?
> tor_set_in_torrc "ClientTransportPlugin" "obfs2,obfs3 exec /usr/bin/obfsproxy managed"
JFTR, obfs2 is deprecated, and we might want to support scramblesuit
instead. This may require a newer obfsproxy package, though, and is
probably orthogonal to the work you're doing presently.
> rm -f /home/tor-launcher/.torproject/.torlauncher/*.default/places.sqlite
Can't we be even more aggressive, and delete the entire
default profile?
> Here are some things I'd like some feedback on:
> # Loss of Vidalia's systray icon
> Since Vidalia is removed, and Tor Launcher doesn't show a systray icon
> indicating Tor's connection state like Vidalia did, there's no
> *constant* indication whether Tor is up and running, just the
> *temporary* notification we recently introduced. I expect that our users
> are heavily trained by now to look for the Vidalia icon.
> Any thoughts on this?
I think that's another reason not to remove Vidalia until we have
a good replacement for it. Perhaps we need a parent ticket called
"Remove Vidalia", with subtasks for every such potential blocker.
> # Loss of old bridge mode explanation
> In our old, Vidalia-based bridge mode, a Tails-specific dialog was shown
> (thanks to our custom patches), and it mentions the "hide that you're
> using Tor" use case. This perspective of bridges is completely absent
> from Tor Launcher's corresponding dialog.
> Is this an issue?
> I suppose that we in the short run can settle with only mentioning this
> use case in our user documentation,
Agreed. More specifically, this documentation will be available from
the greeter, next to the "Use bridges" setting, right?
> In the long run we probably want to convince upstream that this is
> a valid use case and have the description changed/complemented.
Agreed. I think a ticket about it should be created in the Tor
Launcher's Trac.
> # When to show the Tor Launcher network settings window?
> The current implementation shows it for each and every successful
> network connection, and always set's `DisableNetwork` before starting
> Tor to enforce potentially new settings. This way we support changing
> the network settings during the same Tails session.
> I realise that this may be annoying (especially with unstable WiFi
> connections), and may train users to click through the Tor Launcher
> network settings wizard without thinking. Hence we probably want to move
> to some sort of "run only once" approach.
> I think we should immediately drop the "start directly at Gnome desktop
> start" approach, as Tor Launcher requires a running Tor process, which
> has a whole can of worms in the Tails context. What remains is "start at
> first connection", which is simple to implement.
> Does this make sense?
Agreed.
> # What about the non-bridge options, like proxy configuration?
> Tor Launcher's network settings are not limited to bridge settings but
> also deals with proxies and firewalls with egress port filtering. These
> are all relevant things for Tails users, which we supported setting
> previously through Vidalia.
> Since "bridge mode" covers some quite different use cases (and actually
> is incompatible with proxies, see below) we need a separate way to start
> Tor Launcher's network settings. I think adding an entry in Gnome's
> menues is sufficient.
+ some documentation => agreed.
> ## Re-invent or change name of bridge mode?
> An annoying issue, though, is that Tor Launcher requires that the Tor
> process is running before it will show the network settings, so users
> have to connect to a "bad" network before they can configure the option
> needed to make Tor usable on it, like a proxy.
I don't get it, may you please clarify what you mean with "bad
network"?
> OTOH, this was the case with Vidalia too, so it's not a regression.
> One way to fix this issue would be to re-invent bridge mode into
> something that covers all cases where one needs special network
> settings. However, I suspect that that will be conceptually harder to
> get for our users. Or would a combo box with something like "None"
> (default), "Bridge mode", and "Proxy/Fascist Firewall" be ok? All would
> work essentially the same, with setting `DisableNetwork` before Tor
> starts, starting Tor Launcher after, with one little difference:
> Note that only one of `{HTTP{,S},Socks{4,5}}Proxy` and
> `ServerTransportPlugin` can be configured in Tor at the same time, and
> since we have to add a `ServerTransportPlugin` line in order to support
> obfsproxy while in bridge mode, proxies are incompatible with bridge
> mode, so it wouldn't be added in e.g. the "Proxy/Fascist firewall" mode.
I'll assume you mean ClientTransportPlugin here.
> The best would be if Tor Launcher was improved to automatically add an
> appropriate `ServerTransportPlugin` line when a bridge using some TP is
> added. Then "bridge mode" and "Proxy/Fascist Firewall" would become the
> same, and we'd only need a single checkbox with some appropriate wording
> for "I need special network settings".
> Since it's not a regression I don't think it's important to fix it for
> the initial release. However, if we eventually want to fix this that
> means that the UX for this option will change, which would be great to
> avoid. I don't think there's time for that before the 0.23 release
> though, so I guess I'll just drop this for now.
Yes, let's drop this for now... but please create a ticket about it,
paste your notes into a blueprint so that we don't have to dig through
the list archives next time someone wants to work on it.
> # "Copy Tor Log to Clipboard" doesn't work
> Following the nice separation approach we had for Vidalia, I made Tor
> Launcher execute under dedicated user. The problem is that the clipboard
> isn't shared to the Live user, so the button in question does nothing
> from the perspective of the Tails user.
> One solution is to run Tor Launcher as the Live user, and have it use
> WinterFairy's Tor Control Port filtering proxy (#6384), but it'd need to
> be extended quite a bit to support all the commands needed by Tor
> Launcher. It'd be insecure too as it would allow a compromised Live user
> to unconfigure bridges, for instance. I strongly oppose this.
Agreed.
> Do we care about this? Any simple fixes to enable clipboard sharing
> (preferably only one-way) between different users in the same X session?
I use clipboard sharing between different X clients running in the
same X session, as different users, every day. The clients running as
a different user than the one running the session are run with
"ssh -Y". I doubt we want to run sshd in Tails, and I have no idea how
to achieve the same with sudo, sorry. Perhaps give gksudo a try?
But IMHO, we don't care much about it, so I recommend not spending too
much time on it, but still creating a low-priority ticket.
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
