Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Alan: 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] There's no green onion in the quoted emails above that. So I understand that you're agreeing on having a green onion displayed somewhere on the desktop once Tor is started. If not please clarify. 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. I beg to disagree. To me monitoring Tor also means being able to have some clue at any time about whether it's been started or not, from the desktop. So the green onion is part of monitoring Tor for me, it's status icon. At least as far as we agree on keeping that green onion (see the beginning of that mail). - 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. If we agree on keeping the green onion then I don't care whether we have one, two, or n pieces of software. I tend to believe that having one is simpler than having two (when possible) but I don't know GNOME internals as much as you do. If the green onion needs to be a shell extension, then maybe Tor Monitor should be part of that same shell extension. This shell extension would appear as an icon on the desktop and have an option to open a window with the details of the circuits. Like our OpenPGP Applet does: you click on it, choose Encrypt Clipboard with Public Keys, and it opens a window with a list of keys. 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. ___ 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
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. No idea what are the use case for this feature that we would want to support. If someone really wants it, better add it to arm IMO. Tor Monitor doesn't provide this feature yet. It would be very easy to add, even though I'm not sure I find it desirable: currently we only *monitor* Tor. Do we also really want to *control* it? Rather not IMO, but I guess everybody got that already :) I'd love to see Tails run no X application, except Tor Launcher, that is able to trivially deanonymize the user via the control port. Being able to close circuits could be useful to debug malicious exit nodes. For example, you get an unexpected HTTPS or SSH warning, write down the info about your exit node, and close that circuit to get a fresh one and confirm your suspicions. Good catch! How important would that be given it doesn't happen that often? On the other hand I understand the importance of not doing into controlling Tor. Indeed, I'm pretty sure that closing arbitrary circuits offers excellent avenues for de-anonymization attacks. It *might* be possible to mitigate this problem by strongly rate-limiting it, though. If it works, then this might be the easiest way out, but it would need a careful threat modeling and security discussion before I trust it. I think that would be the most elegant way to solve this problem. Everything that follows in this paragraph is just in case nobody works on this potential solution early enough. Do we think that the majority of users who can do this kind of analysis would suffer from having to do it in arm? If not, then the next step is to file a wishlist ticket about it in arm upstream. If yes, then it gets harder, but maybe there are good enough ways out for the users in the grey zone (skilled enough to conduct this analysis, not Unixist enough to be at ease in a terminal-based UI): * For HTTPS, one can already use Torbutton's New Identity feature to achieve the same result. IIRC the upcoming Torbutton's per-tab circuits viewer will have a New circuit for this tab feature, that will make it even better. * For other kinds of connections (ssh, imaps, pop3s, etc.) then there are two ways: - either using arm to trigger a New Identity, which is not *that* crazy: close the software that initiated the connection, open a root terminal (which may be a blocker in itself), run arm, type m, down arrow then enter - or restarting Tor, e.g. by disconnecting and reconnecting from the network using the NM applet = 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. - Has there been any thought put already into how Tor Monitor would integrate into #7437 (Add a progress indicator while establishing a connection to Tor), or live aside of it? I was kinda hoping that removing Vidalia would help consolidating the sources of information we provide to the user about the network bootstrap process: I bet the variety of such sources participate in confusing users. So if Tor Monitor is meant to be an independent tool, perhaps it's better if it does *not* start by default. Anyway, I'm wandering a bit off-topic here, but you don't want me to wait 6 months before I ask this question, right? Right, there's definitely a UX side to this. The first thing I can think of is that people are going freak out if the green onion disappear as its currently the only indicator of the Tor state on the desktop. I'm not talking about the Tor is ready notification which is not an permanent indicator. I'm not sure that this green onion is actually an indicator of the Tor state, see below. We developers know that nothing can do wrong and everything that is not Tor would be blocked. But in term of usable security, I think it's important to have a visual indicator saying hey, everything is all-right. OK. If all we need is to convey the message that everything is configured to go through Tor, then we don't even need to talk to the control port: we can just display a green onion (once Tor has bootstrapped) and leave it there as long as the Tor service is running. I'm half-joking, but seriously, given we *know* that everything is alright, we can just say that in the way people want to hear it, which is apparently that green onion (I'll trust you on that one). And also how shall we let users know when their Internet connection is working but they loose their connection to Tor for some reason (say
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Alan: I was thinking about an application that an user would only launch from the Applications menu/overview. I also thought about a button in the Tor is ready notification. But not launching Tor Monitor automatically means we *need* write access to the control port to list open circuit/streams. I don't get that last sentence... Could you explain a bit more it maybe? Are you saying that starting Tor Monitor automatically or not makes a difference on the type of access (read-only or read-write) that we need to its control port? ___ 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
sajolida wrote (18 Feb 2015 11:36:27 GMT) : Alan: I was thinking about an application that an user would only launch from the Applications menu/overview. I also thought about a button in the Tor is ready notification. But not launching Tor Monitor automatically means we *need* write access to the control port to list open circuit/streams. I don't get that last sentence... Could you explain a bit more it maybe? Are you saying that starting Tor Monitor automatically or not makes a difference on the type of access (read-only or read-write) that we need to its control port? If I spotted the misunderstanding correctly (see the other email I've just sent), and if I guess correctly, it could be that: when simply reading from the control port, Tor Monitor gets notifications about whatever streams and circuits Tor creates etc. But if Tor Monitor is started after Tor has already opened streams and circuits, then it needs to send a GETINFO (or whatever) command to get the list of already existing circuits and streams. Alan, did I guess it right? Cheers, -- intrigeri ___ 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Alan wrote (14 Feb 2015 23:06:15 GMT) : I implemented an automatic reconnection mechanism, and then broke it when adding SOCKS support - but I thought about it? \o/ Do you now a list of other workarounds? Not by heart. I suggest you: * look at the tickets we have open about Vidalia in Redmine * find+grep for vidalia in our source tree, there may be hacks around anywhere in there ___ 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Alan wrote (12 Feb 2015 15:31:41 GMT) : Please clone the repo again, and from Tails/Jessie: sudo apt-get install python-stem python-pysocks sudo ./setup.py install sudo iptables -I OUTPUT 1 -p tcp --dport 9050 -d 127.0.0.1 -m owner \ --uid-owner vidalia -j ACCEPT sudo -u vidalia tormonitor I've tried it, and it looks great, congrats! A few UI remarks: * I like it very much :) * I'm not sure about the subtitle in the title bar, that reads Display Tor circuits and streams: maybe drop Display? Anyway, I'll let sajolida nitpick on such things :) * Displaying circuits without any separator but a space between nodes is hard to read for me. Vidalia uses comma+space as a separator, and it's easier for me to read it this way. * The Name header for the circuits list feels wrong. How about Path instead? * I suspect the circuit status strings should be capitalized. * When I disconnect from the network and then reconnect, Tor Monitor tells me it's going to try to reconnect to Tor, but clicking on the OK button doesn't trigger any visible action and the notification stays in place. Buggy thread/parallelism handling? * When I disconnect from the network and then reconnect, Tor Monitor tells me it's going to try to reconnect to Tor, but it still lists a few circuits from the previous Tor session. Maybe the list should be emptied in such a case? * Tor Monitor needs an icon to display in the task bar instead of the default one :) Great job. Cheers, -- intrigeri ___ 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi, Alan wrote (15 Feb 2015 00:42:34 GMT) : intrigeri intrig...@boum.org wrote: I'd love to understand why this would be more useful than some existing GNOME network monitor that we don't have to maintain, and so far I fail to. You find it desirable, so there's probably a good reason. As an example, when using a poor connection, I like to see if there is Tor traffic going on or not. I must admit I never tried to use GNOME System Monitor for that and that it may very well work (or not). On Tails/Jessie, Applications - Utilities - System Monitor - Ressources seems to address the need you're expressing. We ship it already. Please try it out before writing code that duplicates this existing functionality :) And now, I'll add another candidate feature: - Can access the Tor control port via a tight filtering proxy I'm curious what kind of access the new thing needs. Tor monitor uses stem, and I didn't search about hidden things stem might need. I use methods that directly call: - GETINFO circuit-status - GETINFO stream-status - GETINFO ip-to-country I guess the only way to know is to actually run Tor Monitor behind our filtering proxy, have the latter log refused commands, append to the whitelist until everything works, and then report back what the whitelist is. Are you interested in doing this? And forcibly keeping this access read-only tightens things a bit against X11-based attacks. We need at least to query Tor for its open circuits and streams if we want to be able to start Tor Monitor after Tor. If we can ensure that Tor Monitor connects to Tor before Tor has open any circuit or stream, then it may be possible to have read only access if no command on the control port is needed to be notified of circuit or stream changes. Everything that you're describing here sounds like read-only access to me, so I don't understand what you mean. Does query[ing] Tor for its open circuits and streams need anything else but read-only access? Just to clarify: I count retrieving info about the Tor state (GETINFO) as read-only access, even if technically this is wrong. Maybe that's where the misunderstanding was. The security feature I'm asking for is that Tor Monitor shouldn't be allowed to *configure* Tor, and it should only be allowed to *retrieve* the info it really needs via a GETINFO filter. And a few more questions: - Why does Tor Monitor need to use a Tor SOCKS port? Just curious :) To get details on a path. As Tor currently uses microdescriptors which contains very few information, I use stem remote descriptor downloader, which connects directly to Tor directory. Looking more deeply at what I can get directly from Tor, I just found that I can get the IP and other information missing in microdescriptors from Tor network status, so I'd only miss platform and uptime - which are not visible in Vidalia anymore. I definitely wouldn't miss it if the platform and uptime info disappeared, and we got tighter security as a result. Let's just do that and get rid of the SOCKS port access requirement, then? (The next question will be: what kind of data does it retrieve via this port, how is it used and parsed, but for that I can probably just look at the code.) I use stem.descriptor.remote.DescriptorDownloader. That's the kind of answer I was hoping to get! - Has there been any thought put already into how Tor Monitor would integrate into #7437 (Add a progress indicator while establishing a connection to Tor), or live aside of it? I was kinda hoping that removing Vidalia would help consolidating the sources of information we provide to the user about the network bootstrap process: I bet the variety of such sources participate in confusing users. So if Tor Monitor is meant to be an independent tool, perhaps it's better if it does *not* start by default. Anyway, I'm wandering a bit off-topic here, but you don't want me to wait 6 months before I ask this question, right? I was thinking about an application that an user would only launch from the Applications menu/overview. I also thought about a button in the Tor is ready notification. I like it this way. Cheers, -- intrigeri ___ 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi, 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. No idea what are the use case for this feature that we would want to support. If someone really wants it, better add it to arm IMO. Tor Monitor doesn't provide this feature yet. It would be very easy to add, even though I'm not sure I find it desirable: currently we only *monitor* Tor. Do we also really want to *control* it? Rather not IMO, but I guess everybody got that already :) I'd love to see Tails run no X application, except Tor Launcher, that is able to trivially deanonymize the user via the control port. Being able to close circuits could be useful to debug malicious exit nodes. For example, you get an unexpected HTTPS or SSH warning, write down the info about your exit node, and close that circuit to get a fresh one and confirm your suspicions. Good catch! How important would that be given it doesn't happen that often? On the other hand I understand the importance of not doing into controlling Tor. Indeed, I'm pretty sure that closing arbitrary circuits offers excellent avenues for de-anonymization attacks. It *might* be possible to mitigate this problem by strongly rate-limiting it, though. If it works, then this might be the easiest way out, but it would need a careful threat modeling and security discussion before I trust it. I think that would be the most elegant way to solve this problem. Everything that follows in this paragraph is just in case nobody works on this potential solution early enough. Do we think that the majority of users who can do this kind of analysis would suffer from having to do it in arm? If not, then the next step is to file a wishlist ticket about it in arm upstream. If yes, then it gets harder, but maybe there are good enough ways out for the users in the grey zone (skilled enough to conduct this analysis, not Unixist enough to be at ease in a terminal-based UI): * For HTTPS, one can already use Torbutton's New Identity feature to achieve the same result. IIRC the upcoming Torbutton's per-tab circuits viewer will have a New circuit for this tab feature, that will make it even better. * For other kinds of connections (ssh, imaps, pop3s, etc.) then there are two ways: - either using arm to trigger a New Identity, which is not *that* crazy: close the software that initiated the connection, open a root terminal (which may be a blocker in itself), run arm, type m, down arrow then enter - or restarting Tor, e.g. by disconnecting and reconnecting from the network using the NM applet = 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. To go back to the information we should provide about the circuits: 1. Be able to know the country of your exit node can be useful to understand some limitations it might have when trying to access some ressources (eg. YouTube in Germany). Indeed, would be useful. 2. We should have a look at what Tor is planning to integrate to their browser as they are already solving a similar problem. I think. Full ACK. It'll be in Tor Browser 4.5a4, due in ~1 week, if I got it clearly. - Has there been any thought put already into how Tor Monitor would integrate into #7437 (Add a progress indicator while establishing a connection to Tor), or live aside of it? I was kinda hoping that removing Vidalia would help consolidating the sources of information we provide to the user about the network bootstrap process: I bet the variety of such sources participate in confusing users. So if Tor Monitor is meant to be an independent tool, perhaps it's better if it does *not* start by default. Anyway, I'm wandering a bit off-topic here, but you don't want me to wait 6 months before I ask this question, right? Right, there's definitely a UX side to this. The first thing I can think of is that people are going freak out if the green onion disappear as its currently the only indicator of the Tor state on the desktop. I'm not talking about the Tor is ready notification which is not an permanent indicator. I'm not sure that this green onion is actually an indicator of the Tor state, see below. We developers know that nothing can do wrong and everything that is not Tor would be blocked. But in term of usable security, I think it's important to have a visual indicator saying hey, everything is all-right. OK. If all we need is to convey the message that everything is configured to go through Tor, then we don't even need to talk to the control port: we can just display a green onion (once Tor has bootstrapped) and leave it there as long as the Tor service is running. I'm half-joking, but seriously, given we *know* that everything is alright, we can just say that in the way people want to hear it, which is
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi, Alan wrote (12 Feb 2015 15:32:15 GMT) : - Ability to close a circuit manually. No idea what are the use case for this feature that we would want to support. If someone really wants it, better add it to arm IMO. Tor Monitor doesn't provide this feature yet. It would be very easy to add, even though I'm not sure I find it desirable: currently we only *monitor* Tor. Do we also really want to *control* it? Rather not IMO, but I guess everybody got that already :) I'd love to see Tails run no X application, except Tor Launcher, that is able to trivially deanonymize the user via the control port. - Bandwidth Graph. Advanced feature IMO, already present in arm. If we care much about getting this info graphically, then I think some GNOME system monitor would be a better tool to satisfy the need (it would be a suitable replacement in the context of Tails, since we're routing almost everything through Tor). It would be possible (and I think desirable) [...] I'd love to understand why this would be more useful than some existing GNOME network monitor that we don't have to maintain, and so far I fail to. You find it desirable, so there's probably a good reason. Let me try harder to understand: In which use cases is the Tor bandwidth traffic info more useful than the overall system network traffic? (I can see the heavy I2P + Tor user one, but this can't be a good enough reason to write and maintain this code given we have arm already, I guess.) Or is it a matter of UX, as in users would find the tool more easily if it was accessible from the Tor Monitor's interface? I've no idea, and it might very well be the case. But then perhaps we can start whatever network traffic monitor we want from Tor Monitor. And now, I'll add another candidate feature: - Can access the Tor control port via a tight filtering proxy I'm curious what kind of access the new thing needs. And forcibly keeping this access read-only tightens things a bit against X11-based attacks. And a few more questions: - Why does Tor Monitor need to use a Tor SOCKS port? Just curious :) (The next question will be: what kind of data does it retrieve via this port, how is it used and parsed, but for that I can probably just look at the code.) - Assuming it really does need access to a SOCKS port: how about using the SOCKS port meant for Tails-specific traffic, instead of the fallback one? - Has there been any thought put already into how Tor Monitor would integrate into #7437 (Add a progress indicator while establishing a connection to Tor), or live aside of it? I was kinda hoping that removing Vidalia would help consolidating the sources of information we provide to the user about the network bootstrap process: I bet the variety of such sources participate in confusing users. So if Tor Monitor is meant to be an independent tool, perhaps it's better if it does *not* start by default. Anyway, I'm wandering a bit off-topic here, but you don't want me to wait 6 months before I ask this question, right? Cheers, -- intrigeri ___ 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Alan wrote (09 Feb 2015 20:57:52 GMT) : Do we miss something else to replace Vidalia ? It would make sense to look at the Vidalia bugs we've suffering from for years, to ensure we can drop our workarounds. E.g. the fact Vidalia doesn't auto-reconnect to Tor when the latter is restarted (#7614). ___ 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi, sajolida sajol...@pimienta.org wrote: I cloned your repo, installed python-stem, tried to run setup.py and tormonitor.py and got errors for both. How can I test this from Tails? $ python setup.py File setup.py, line 10 requires=['stem','gi'] ^ SyntaxError: invalid syntax Sorry I messed up the initial commit. Please clone the repo again, and from Tails/Jessie: sudo apt-get install python-stem python-pysocks sudo ./setup.py install sudo iptables -I OUTPUT 1 -p tcp --dport 9050 -d 127.0.0.1 -m owner \ --uid-owner vidalia -j ACCEPT sudo -u vidalia tormonitor For the rest of the questions see my other email in this thread. 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi, intrigeri intrig...@boum.org wrote: sajolida wrote (11 Feb 2015 15:12:02 GMT) : $ python tormonitor.py [Errno 13] Permission denied Traceback (most recent call last): File tormonitor.py, line 346, in module app = TorMonitorApplication() File tormonitor.py, line 316, in __init__ message_format=_(Unable to connect to Tor daemon.)) Seems that there's a bug in this code path. I don't think that there is a bug in this code path. You need Gtk = 3.14 (basically Jessie). Please clone the repository again as I messed up the initial commit. And/or maybe you're hitting this bug because you're running the code as the `amnesia' user, who cannot talk to the Tor control port. Try as the vidalia user? The user running tormonitor must have access to Tor control socket *and* to Tor SOCKS port. In Tails/Jessie: sudo iptables -I OUTPUT 1 -p tcp --dport 9050 -d 127.0.0.1 -m owner \ --uid-owner vidalia -j ACCEPT sudo -u vidalia tormonitor Do we miss something else to replace Vidalia ? [...] - Info about relays in the circuits. Would be useful, but not a blocker IMO, since that's an advanced feature and is already provided by arm. Tor Monitor provides this info. - Ability to close a circuit manually. No idea what are the use case for this feature that we would want to support. If someone really wants it, better add it to arm IMO. Tor Monitor doesn't provide this feature yet. It would be very easy to add, even though I'm not sure I find it desirable: currently we only *monitor* Tor. Do we also really want to *control* it? - Ability to view logs from Tor without an administration password. Not sure what action one can easily take based on the info found in these logs, without an administration password. I say we can forget that one too. If someone really wants it, better add it to arm IMO. That would be quite easy to add it there is a consensus that it is useful. - New identity (the one we have in Tor Browser does something different). We had plans (#5716) to hide this Vidalia feature, so I don't think we should add it to this new GUI. This feature is available in arm already anyway, for advanced users who know what they're doing, and for people who insist on shooting themselves in the foot. Easy to add, even though I'm not convinced for the same reason as Close circuit - Bandwidth Graph. Advanced feature IMO, already present in arm. If we care much about getting this info graphically, then I think some GNOME system monitor would be a better tool to satisfy the need (it would be a suitable replacement in the context of Tails, since we're routing almost everything through Tor). It would be possible (and I think desirable) to add a bandwidth graph to Tor Monitor and I already thought about it. But I don't know how to implement that in Gtk yet, and I'd better see this as a fun item than as a required feature. Patches are welcome though, and if there is a consensus that it is required I'll do it. Which one of those are you covering already or did you consider? IMO we should focus on the basic features we would strongly miss if we drop Vidalia, and leave anything more advanced to arm. This way, we keep our maintenance workload to the bare minimum, and provide a simpler GUI. I agree on that. Currently Tor Monitor provides circuit and associated streams, and infos on relays in a circuit. We could add the logs easily and the bandwidth graph less easily to provide a nice monitor. I'm not sure that the other features are desirable. 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi, sajolida wrote (11 Feb 2015 15:12:02 GMT) : $ python tormonitor.py [Errno 13] Permission denied Traceback (most recent call last): File tormonitor.py, line 346, in module app = TorMonitorApplication() File tormonitor.py, line 316, in __init__ message_format=_(Unable to connect to Tor daemon.)) Seems that there's a bug in this code path. And/or maybe you're hitting this bug because you're running the code as the `amnesia' user, who cannot talk to the Tor control port. Try as the vidalia user? Do we miss something else to replace Vidalia ? If I quickly go through what's left from the Vidalia interface and I could discuss the relevance of the following features: Thanks for asking this question! - Info about relays in the circuits. Would be useful, but not a blocker IMO, since that's an advanced feature and is already provided by arm. - Ability to close a circuit manually. No idea what are the use case for this feature that we would want to support. If someone really wants it, better add it to arm IMO. - Ability to view logs from Tor without an administration password. Not sure what action one can easily take based on the info found in these logs, without an administration password. I say we can forget that one too. If someone really wants it, better add it to arm IMO. - New identity (the one we have in Tor Browser does something different). We had plans (#5716) to hide this Vidalia feature, so I don't think we should add it to this new GUI. This feature is available in arm already anyway, for advanced users who know what they're doing, and for people who insist on shooting themselves in the foot. - Bandwidth Graph. Advanced feature IMO, already present in arm. If we care much about getting this info graphically, then I think some GNOME system monitor would be a better tool to satisfy the need (it would be a suitable replacement in the context of Tails, since we're routing almost everything through Tor). Which one of those are you covering already or did you consider? IMO we should focus on the basic features we would strongly miss if we drop Vidalia, and leave anything more advanced to arm. This way, we keep our maintenance workload to the bare minimum, and provide a simpler GUI. Cheers, -- intrigeri ___ 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Alan: Vidalia is unmaintained and we were looking for solutions to get rid of it[1]. It turned out that the main missing piece was a replacement to its Network Map[2]. Great, thanks a lot for moving this forward! I'm working on an GTK application that shows circuits and the streams that are attached to then, basically as the bottom left part of Vidalia's network map[3]. It is now usable so I propose that we get rid of Vidalia for tails/jessie. I cloned your repo, installed python-stem, tried to run setup.py and tormonitor.py and got errors for both. How can I test this from Tails? $ python setup.py File setup.py, line 10 requires=['stem','gi'] ^ SyntaxError: invalid syntax $ python tormonitor.py [Errno 13] Permission denied Traceback (most recent call last): File tormonitor.py, line 346, in module app = TorMonitorApplication() File tormonitor.py, line 316, in __init__ message_format=_(Unable to connect to Tor daemon.)) File /usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py, line 485, in __init__ **kwds) File /usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py, line 418, in __init__ if flags Gtk.DialogFlags.MODAL: TypeError: unsupported operand type(s) for : 'NoneType' and 'GtkDialogFlags' The network status would be provided by this new Tor Monitor. Do we miss something else to replace Vidalia ? If I quickly go through what's left from the Vidalia interface and I could discuss the relevance of the following features: - Info about relays in the circuits. - Ability to close a circuit manually. - Ability to view logs from Tor without an administration password. - New identity (the one we have in Tor Browser does something different). - Bandwidth Graph. Which one of those are you covering already or did you consider? ___ 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.
[Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi, Vidalia is unmaintained and we were looking for solutions to get rid of it[1]. It turned out that the main missing piece was a replacement to its Network Map[2]. I'm working on an GTK application that shows circuits and the streams that are attached to then, basically as the bottom left part of Vidalia's network map[3]. It is now usable so I propose that we get rid of Vidalia for tails/jessie. The network status would be provided by this new Tor Monitor. Do we miss something else to replace Vidalia ? Cheers [1]: https://labs.riseup.net/code/issues/6841 [2]: https://labs.riseup.net/code/issues/6842 [3]: http://git.tails.boum.org/alan/tor-monitor/ ___ 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.
