anonym wrote (04 Mar 2014 20:25:27 GMT) :
>> It could be worth restricting the arguments that amnesia can pass to
>> this command. That would be none, or --force-net-config, right?
> We only need to call it with --force-net-config. Actually, that sudo
> rule was intended for the GNOME menu entry that we're now not so sure we
> want to add after all. I left it there with the option forced.
According to the discussion we had elsewhere, I've just removed this
additional privilege given to the desktop user, since it is not used
right now.
>> In /usr/local/sbin/tails-tor-launcher, I'd rather see the four
>> instances of:
>>
>> VAR=value
>> export VAR
>>
>> ... written "export VAR=value" instead, but that's purely a matter of
>> personal taste, and I don't care much.
> That's a bashism that just happens to work in dash too. It should be
> noted that the very similar bashism `local VAR=value` does *not* work in
> dash. As I've been bitten by the latter one quite severely at one point
> (when working on persistence in live-boot) I've come to prefer the POSIX
> way at all times.
Understood, thanks for the clarification.
>>> Don't ever run Vidalia with -bridgeconf.
>>
>> So we could update our Vidalia package:
>>
>> 1. to drop vidalia-bridgeconf.patch: not needed anymore
>> 2. to hide bridge settings (either in
>> tails-remove-useless-controls.patch, or with a new patch, whatever
>> is more practical)
>>
>> I guess #1 is not a blocker, but I'm unsure about #2. What happens if
>> a user changes bridges settings in Vidalia, after having set it in Tor
>> Launcher? And after *not* having set it in Tor Launcher?
> In both situations the bridges are changed, no more no less. Was there
> any specific potential problem you thought of?
> The one issue I can think of at the moment is that Tor Launcher (thanks
> to my modifications to it) will add an appropriate ClientTransportPlugin
> line to Tor when bridges are input through it, but vidalia won't.
I wasn't thinking of a specific potential problem (apart of user
confusion, due to providing multiple interfaces to the same settings).
But it was not obvious to me that this would not cause any
subtle problem.
Anyway, that's not a blocker for 0.23, but the potential for user
confusion, that implies additional user support work, seems enough to
me to hide these settings in Vidalia. So, I've created #6844.
Obviously, if you disagree, we can reconsider :)
> I've rebased the branch completely since I've imported a new Tor
> Launcher. However, you can review again from after commit 7d0ea0b (which
> corresponds to where your review ended last time). The only thing that's
> happened before that except the Tor Launcher bump is that I dropped the
> commit introducing authbind, per you suggestion. From now on I'll fix
> the Tor Launcher bumps differently to avoid history rewrites.
OK, code review passes, pushed two minor commits (one comment + a note
added to the blueprint) on top. Time to test!
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
