28/02/14 14:08, intrigeri wrote:
> 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).
Apparently I misunderstood, so this is now reverted.
>> 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.
Done.
> Also, probably add -n.
This cannot be done (AFAIK) since I switched to gksudo (for clipboard
sharing; see below).
>> 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.
I certainly meant to anchor it. Fixed now.
> 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.
How can the `sed` call fail exactly?
> 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?
Agreed. This was reverted and a ferm rule put in its palce.
>> 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.
It's othogonal yes, but the point is now moot; I've updated Tor Launcher
to add the line itself for whatever bridges added through it.
>> rm -f /home/tor-launcher/.torproject/.torlauncher/*.default/places.sqlite
>
> Can't we be even more aggressive, and delete the entire
> default profile?
No, some of the prefs are relevant, e.g. the one that makes Tor Launcher
not show its settings upon start, which we want when we reconnect to a
network.
>> 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.
Right, this is a non-issue now.
>> # 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?
Something like that -- it's on sajolida's plate.
>> 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.
I have this on my personal TODO.
[...]
>> ## 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"?
With "bad" I just meant a network that requires a proxy, bridges etc.
Sorry for being unclear.
>> 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. [...]
>> 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".
[...]
> 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.
After some off-list discussion we decided that this actually was the
best, so Tor Launcher has been improved, and all the rest of this was
implemented.
>> # "Copy Tor Log to Clipboard" doesn't work
[...]
> 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?
Running it with gksudo solved it!
Thanks a lot for the review!
Cheers!
