Re: [tor-talk] Review request: TorVM implementation in Qubes OS: Vidalia

[adrelanos <adrelanos@xxxxxxxxxx>]

Abel Luck:
> adrelanos:
>>> Future Work  Integrate Vidalia
>>
>> About Vidalia again... I was quickly reading my dev ticket again (
>> https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev#SHELLSCRIPTSVidaliabydefaultGraphicalGatewayWAITINGFORVIDALIA0.3.x
>> ), why it's not yet integrated into Whonix.
>>
>> Summary:
>>
>> "One drawback with Vidalia 0.2.15 remains... As soon as you edit torrc
>> with Vidalia (i.e. add non-obfuscated bridges, all comments in torrc get
>> lost, i.e. comments how to add obfuscated bridges get lost.).
>>
>> Solved in 0.3.2-alpha. I am waiting for 0.3.2."
>>
>> Another issue was, that Vidalia is explicitly not designed to manage a
>> system wide installed Tor. Vidalia can not start/stop a Tor instance, it
>> has not started itself.
>>
>> Vidalia will also not be able to edit /etc/tor/torrc out of the box,
>> because Vialia gets started as user, while /etc/tor/torrc is owned by root.
>>
>> I am not sure how to solve it best...
>>
>> Running Tor/Vidalia as user is also not the best option, that would
>> prevent "sudo service restart tor" (probable also the Fedora
>> equivalent). Breaking "sudo service restart tor" and running Tor as user
>> is bad, since it can not be updated with by the system apt-get (or the
>> Fedora equivalent). (Imagine long running servers.)
>>
>> I guess the best might be to have Tor managed by the system (apt-get...)
>> and to start Vidalia as a user. To edit /etc/tor/torrc, Vidalia needs an
>> exception to have write rights on that file. Vidalia's start/stop Tor
>> feature will break, I don't know how that could be solved. You still had
>> a Tor which is partially managed by gui and partially managed by cli.
>> Relaxing permission on Tor's data dir further for Vidalia broke Tor.
>>
>> However, in qubes-os that all might be simpler to solve. Tor/Vidalia get
>> updated from dom0?
> 
> No, no, nothing is updated from dom0.  All these problems still apply to
> Qubes.  A further problem is at tor runtime I need to detect the IP
> address of the internal interface, so a static torrc doesn't work.
> 
> Moreover, wrt the New Identity button. With several client VMs, multiple
> apps using different SOCKSPorts, the behavior of New Identity is confusing.
> 	Does pushing it tear down and construct new circuits for
> 	everything? Only the TransPort? Only X?
> 
> Vidalia is extremely useful however, so I need to find some way to
> include it. I wonder if the "best" solution isn't to scrap Vidalia and
> make something new?

Unless you feel, that the Vidalia code base is bad and you better start
fresh, I think it's better to improve Vidalia rather than starting fresh
and it's quite difficult and time consuming to develop such as thing.

https://www.torproject.org/projects/arm.html.en
https://trac.torproject.org/projects/tor/wiki/doc/stem

https://trac.torproject.org/projects/tor/query?component=Vidalia&col=id&col=summary&col=type&col=status&col=priority&col=milestone&col=component&order=priority

https://trac.torproject.org/projects/tor/query?component=arm&col=id&col=summary&col=component&col=type&col=status&col=priority&col=milestone&order=priority

Look quite scary.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk