Hi,
Alan wrote (22 Feb 2015 01:48:28 GMT) :
> intrigeri <intrigeri@???> wrote:
>> Alan wrote (20 Feb 2015 19:43:10 GMT) :
>> > 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.
>>
>> What would be a better place to do it in your opinion?
>>
> In my opinion, the easiest method to replace vidalia's green onion
> would be to write a very small GNOME Shell extension that would listen
> to a very simple DBus service.
Did I get it right that this extension will actually *provide* that
DBus service? And then other stuff (see below) will connect to it to
notify the extension that Tor is up?
> The very same mechanism that currently
> displays the "Tor is ready" notification in Tails would trigger a
> notification to this DBus service that would update this onion. I admit
> this would be very Tails specific.
I think we can go this way (or similar) for the first iteration, that
replaces what Vidalia gives us, including the buggy green onion.
So I've created #9002, as a child ticket of #6841 ("Replace Vidalia").
Now, in the first iteration, the information we want to convey to that
Shell extension is exactly one bit ("Tor is ready", and possibly "Tor
is down" on network post-down). Using DBus to convey this information
seems vastly overkill to me, to the point of being a little
bit ridiculous.
If that saves us time for the next iterations, why not. But for the
next iterations of that extension, the listening direction may change
(I expect that something else will provide the DBus service that
provides updates wrt. the status of Tor connectivity, and the Shell
extension will connect to that service to get these updates), so
perhaps it's really not useful to get DBus onboard before we have
a clearer idea of the design for the next iterations.
An alternative, for the initial iteration, is to do exactly what we're
doing now: when we display "Tor is ready", simply enable the Shell
extension that displays the green onion. And disable it when the
network gets disconnected. This way, we don't even need any
communication channel :)
> Please note that I'm not aware of such a concept of "connectivity
> status" in Tor. If you know about it, don't hesitate to point me to
> relevant documentation.
No idea. Is it equivalent to having circuits open? I think Tor tries
to maintain circuits open even when they're not requested by clients,
so if there's no circuit open, perhaps Tor can be considered
as disconnected?
>> However, splitting it out has a few clear disadvantages:
>>
>> 1. That's one more (presumably Python) process to run, which eats
>> memory etc. Of course, if we go this way, then we don't have to
>> run Tor Monitor by default, so it's only one *more* process for
>> users who manually start Tor Monitor, but still.
>>
> Looks to me that you basically destroyed you own argument...
... only if we don't care about people who will run Tor Monitor.
>> 2. I suspect that this program will be doing very similar things to
>> Tor Monitor under the hood, and then we may quickly have more code
>> duplication than reasonable.
>>
> If we only care about "connectivity status" I'm very unsure that there
> would be code duplication.
OK. At least the "reconnect to Tor when it restarts" part would need
to be implemented on both sides, I guess. But that's probably not
much, and you're probably right.
>> Granted, none of these arguments is very strong, except perhaps the
>> last one. If that backend program + Shell extension were shipped in
>> the same upstream project as Tor Monitor, then #2 and #4 are done
>> with, and I'm happy. Maybe we can reach a consensus on this design?
>>
> I'd agree on that. But I'm not opposed either on integrating a DBus
> interface more strongly in the current Tor Monitor application if:
> - it proves to be actually useful;
> - I get some help with the programming design. If you have a look at
> current code, you'll see that UI code is highly mixed with
> communicating with Tor. That didn't look ugly to me as stem already
> implements most of the logic. But to expose the same (or a subset of)
> this data on DBus, we'd need to redesign this a lot.
Absolutely (after finally having glanced over the code).
> An advantage if such an approach is that there is no reason why the
> DBus service would run the same unix user as the UI. So if the UI would
> only get its information from the DBus service, then we don't need any
> access to the Tor control port for the user running the UI.
I'm very skeptic about having the Tor Monitor UI get all the info it
needs over DBus. The backend would not only have to let it know about
updates, but also about Tor's initial state on Tor Monitor startup.
I already see how racy this can become with three different event
loops (Stem's, DBus' and GTK's) in the mix and a pile of async' code.
IMO it's simply not worth the added complexity.
I'm not convinced by the security benefits either, but I'll elaborate
on that when replying to your follow-up email that has a more
detailed proposal.
> To sum up, I see three options (on order of complexity) to feed this
> GNOME shell extension that would provide the onion:
> 1. through the same mechanism that displays the "Tor is ready"
> notification;
> 2. through a DBus service that would be a separate process that the
> Tor Monitor application (but managed in the same project);
> 3. through a DBus service that would be tightly integrated in the Tor
> Monitor application.
I say let's go with (1) as far as #6841 is concerned.
Then we can think of this in more depth once Vidalia has been removed,
and you're starting work on the next iterations, with #7438 in mind:
then we'll have more info about what the consumers of that DBus
service would be. We're not there yet.
Cheers,
--
intrigeri
