Hi again,
On Thu, 19 Feb 2015 14:23:03 +
sajolida sajol...@pimienta.org wrote:
intrigeri:
sajolida wrote (18 Feb 2015 11:32:17 GMT) :
intrigeri:
Alan wrote (12 Feb 2015 15:32:15 GMT) :
- Ability to close a circuit manually.
[...]
= seems like we can address this corner case in a good-enough way
without compromising security nor spending large amounts of energy on
this topic.
Fine with me. Still, we would need to have arm documented in the first
place. And since I propose it to go in Advanced topics anyway we can
explain the workaround there for now and create the upstream ticket that
you mentioned as well.
+1
[About the green onion]
Now... does Vidalia really do that? In other words, does Vidalia's
green onion really turn yellow or red or something whenever this
happens? I don't think so: I *believe* that Vidalia's onion indicator,
once it has turned green, only reflects the state of Vidalia's
connection to the Tor control port, not the state of the tor daemon's
connection to the Tor network. I don't remember seeing it change
colors unless I e.g. restarted Tor. I'd be happy to be proven wrong,
though :)
Same for me, I'm pretty sure that Vidalia stays green forever once Tor
is started.
...until Vidalia loose connection to the Tor daemon.
And I'm fine with mimicking this behavior for a start if
that's easier to implement (no regression), but I think this is buggy
(the onion shouldn't be green if Tor is not in a working state anymore).
I want to replace Vidalia to get rid of its bugs not to reimplement them :)
but would it be conceivable to have Tor Monitor
appear as green onion on the desktop as Vidalia does until now?
I don't think it's the way to go:
- I'd like Tor Monitor to stay a generic application, with a clear
focus on being a monitor for Tor and showing whatever icon on the
desktop doesn't look like the same task for me.
- System Tray Icons were deprecated in Gtk since 3.14. A proper
implementation of this green onion for GNOME 3 desktop would be a
(very simple) Shell extension, to which we (the NetworkManager
hook) should send a DBus signal (or the opposite). That might be a
tiny funny project.
[...]
Yes, and if I understood correctly Tor Monitor currently needs Tails
Jessie. So an obvious roadmap would be to have a working replacement of
Vidalia with Tor Monitor (without regressions) in Tails Jessie. Does
that sound realistic? Then only we can work on making it better (eg.
smarter onion status icon, progress bar while starting Tor, etc.).
And if Tor Monitor is always running in the background, then maybe it
could also provide information while Tor is starting and be the right
tool to solve #7437 in the future?
That's what I had hidden in the back of my head when asking this
question initially :)
I'm not opposed to exposing a DBus interface in a future version of
TorMonitor to provide the green onion or other applications more
information that our hooks could. But I'm not sure it is the right
place to do it yet.
The main problem I see with this approach is: if we go this way, then
either Tor Monitor stops being a generic tool, but becomes yet another
Tails-specific thing, which would make me sad.
Let's try to make it generic straight away! I'd love to have it on my
regular Debian as well.
Me too! I'm not really into solving all the issues we have in this
application.
I thought about it
a bit harder, and now it's not obvious to me what we would gain by
merging the two tools we need into a single one:
* Tails could start the Tor bootstrap and time sync progress monitor.
Upon completion, this piece of software would either just
terminate, or (if we need a permanent indicator that's tight to the
actual Tor status) start Tor Monitor --hide-in-taskbar, that would
display some onion.
* Anyone else would just use Tor Monitor.
And then this topic becomes mostly orthogonal to the current
discussion, I think :)
For the reasons I exposed before, I don't think it's the right
solution. But you can try to convince me...
Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.