Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails
24/02/14 16:54, Kathleen Brade wrote: On 2/20/14, 4:15 PM, anonym wrote: Any ETA on when my patches can be reviewed? ... Feedback from Mark and myself for: [...] Thanks for the review! Before actually fixing any of your concerns I'd to know how you'd like me to prepare these additional changes. Do you want them in new commits (easier to review), or do you want me to rewrite the history by fixing the old commits (nicer VCS history)? 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] Tor Launcher as a standalone XUL app in Tails
On 2/25/14, 1:24 PM, anonym wrote: ... Do you want them in new commits (easier to review), or do you want me to rewrite the history by fixing the old commits (nicer VCS history)? We prefer nicer/shorter revision history. Thanks! -- Kathy ___ 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] Tor Launcher as a standalone XUL app in Tails
Mark Smith: Another small consideration is that we (TBB developers) will probably not test Tor Launcher as a standalone XUL application because we will not be using it that way... so it is possible we will accidentally break something that is needed in that mode. Of course we will try not to do so. As long as Tor Launcher more or less sticks with its current design, and continues to keep away from stuff directly affecting Firefox (leaving that to Tor Button) and only do stuff related to starting/configuring/monitoring Tor processes, I expect very little problems due to your upstream changes. Does this look like your plan for the foreseeable future? Yes, although I leave it to Mike (in his role as TBB chief architect) to comment as well. Requirements may dictate a future change in direction, but for now the plan is for Torbutton and Tor Launcher to work together but maintain their distinct roles. Yes, I think it is reasonable to assume that Tor Launcher should behave independently of Firefox (modulo minor oversights). In addition to XULRunner/Tails, we want it to continue to work with Thunderbird, and be easy to port to Instantbird, as well. To what degree does Tails have automated testing? Will you be able to keep an eye on 'master' and tell us if you run into problems? As far as the patches, they should have a Tor Launcher ticket to correspond to them. Perhaps attach them there? -- Mike Perry signature.asc Description: Digital signature ___ 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] Tor Launcher as a standalone XUL app in Tails
25/02/14 23:46, Mike Perry wrote: Mark Smith: Another small consideration is that we (TBB developers) will probably not test Tor Launcher as a standalone XUL application because we will not be using it that way... so it is possible we will accidentally break something that is needed in that mode. Of course we will try not to do so. As long as Tor Launcher more or less sticks with its current design, and continues to keep away from stuff directly affecting Firefox (leaving that to Tor Button) and only do stuff related to starting/configuring/monitoring Tor processes, I expect very little problems due to your upstream changes. Does this look like your plan for the foreseeable future? Yes, although I leave it to Mike (in his role as TBB chief architect) to comment as well. Requirements may dictate a future change in direction, but for now the plan is for Torbutton and Tor Launcher to work together but maintain their distinct roles. Yes, I think it is reasonable to assume that Tor Launcher should behave independently of Firefox (modulo minor oversights). In addition to XULRunner/Tails, we want it to continue to work with Thunderbird, and be easy to port to Instantbird, as well. Excellent! To what degree does Tails have automated testing? While we have an automated test suite that we run on release time, we're not quite there yet to have it run on nightly basis. To automatically package and test the development branches of various applications (our own, Tor Launcher, etc.) is yet another step but we do have plans in that direction. Will you be able to keep an eye on 'master' and tell us if you run into problems? I suppose that for now this will become a manual step for the Tails Release Manager, similar to how we try to keep in sync with your TBB work. As far as the patches, they should have a Tor Launcher ticket to correspond to them. Perhaps attach them there? Done in ticket #11074 (and children). 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] Tor Launcher as a standalone XUL app in Tails
On 2/20/14, 4:15 PM, anonym wrote: Any ETA on when my patches can be reviewed? ... Feedback from Mark and myself for: 0001-Support-packaging-as-a-standalone-XUL-application.patch -- For the Makefile: A small issue: Mark and I would prefer that files not be copied into the src tree during packaging. An alternative would be to stage the files under pkg (I realize that will be more work). For application.ini.in: Why do you have MinVersion set to 17.0.0? Unless for some reason you need MinVersion set to 17, you should make it 24.0.0. At this point, we really don't want anyone running with Gecko older than 24. We are going to change the minVersion in Tor Launcher's install.rdf file to 24.0.0 as well. Feedback for: 0002-Split-Tor-process-starting-code-from-control-code.patch -- For tl-process.js: Mark and I prefer that the line setting mTorProcessStatus to unknown be left in _startTor(). Some day we may call that multiple times and we'll want it initialized correctly in there. The status is initialized to unknown (0) upon creation so you do not need to set it in _controlTor(). Feedback for: 0003-If-TOR_CONFIGURE_ONLY-1-only-configure-Tor.patch -- For tl-process.js: Please fix the else to be on its own line (to match the rest of the file). For tl-util.jsm: It would be nice if shouldOnlyConfigureTor() had a corresponding pref like shouldStartAndOwnTor() does (other people may find the concept useful). Perhaps extensions.torlauncher.only_configure_tor? Feedback for: 0004-If-FORCE_NET_CONFIG-is-set-show-network-settings-iff.patch -- Please change FORCE_NET_CONFIG to TOR_FORCE_NET_CONFIG. Thanks! -- Kathy ___ 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] Tor Launcher as a standalone XUL app in Tails
anonym wrote (19 Feb 2014 19:14:40 GMT) : The primary profile can be used offline too. For instance, if a link in some GNOME notification is clicked, Iceweasel using the primary profile will be opened. We'd some how need to make Tor Launcher *not* run when the browser is opened while offline (start with `TOR_SKIP_LAUNCH`?). But then, if the browser was opened while offline and we then connect to a network (and we are in bridge mode), then the NM hook will want to start the already running browser with the envvar that will show Tor Launcher's network settings and then exit the browser. How can all this be achieved without creating a complete mess? OK. From the top of my head, two vaguely related notes: * We'll want to run Tor Launcher *only* when the user has ticked a checkbox in the Greeter, right? Or do we run it in all cases? * Note that we don't run the browser by default on network connection. See the wrapper in /usr/local/bin/iceweasel. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ 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] Tor Launcher as a standalone XUL app in Tails
On 2/19/14, 2:14 PM, anonym wrote: It sounds to me like the setting you are talking about does *not* have any direct effect on Firefox, only on Tor Launcher. To clarify, you are *not* setting e.g. `network.proxy.socks` (which Firefox itself uses), instead you are setting e.g. `extensions.torlauncher.xxx` (which Firefox itself doesn't use). Is this correct? (If so, we're happy -- see the end of this email.) Yes, I think that is correct. It is a little difficult for Kathy and me to separate the two things because until now we have never thought about Tor Launcher running in a profile separate from the one where browsing will be done. This is also why we need to start tor with DisableNetwork=1 when the use default bridges option is enabled: so we can update the bridge configuration before tor starts its bootstrap process. See: https://trac.torproject.org/projects/tor/ticket/10418 [Note: The reason I'm continuing this part of the discussion is not because I think it will be especially relevant for Tails directly but it does help me to better understand where Tor Launcher is going in the future so I can assess if Tor Launcher in Tails is a long-term solution or not. It may be that I'm just wasting everyone's time here being confused and speculating about a future change that I don't know the exact details of, so we may want to just drop it. :)] Will anything change with Tor Launcher's current design of immediately starting Tor and configure it to use the previous settings on all runs after the very first? Otherwise I don't see the relevance of setting `DisableNetwork=1` beyond the first run; if the use default bridges option was chosen on first run, bridges will be written into torrc, which makes `DisableNetwork=1` redundant. However, if the design does change, e.g. that you show the network settings on *each* run, with `DisableNetwork=1` set (highly relevant now since the user may have chosen connect in the clear in the previous run), then I don't see why you thought this new behaviour would be incompatible earlier patch (0002-Always-open-network-settings-if-DisableNetwork-is-se.patch). I tried to explain this in my last message but possibly I wasn't clear. We do not plan to show the network configuration wizard each time. The issue is that Tor Launcher needs to reconfigure the default bridges each time tor starts up. This is necessary because the default bridge addresses may change when TBB is upgraded (the addresses are stored as a series of hidden Tor Launcher preferences). I am not sure if the concept of default bridges is something you will want for Tails in the future or not. It doubt it. In Tails we care about the bridges being non-public to support the hide that you are using Tor use case as best we can. If we expose our users to a convenient option to use a public list of default bridges, then we put the users of that use case at risk. Therefore it'd be great if whatever GUI control you'll use for this option will be hidden (or at least disabled/greyed out) if the pre-supplied list of default bridges is empty/non-existent. That is already how things work. The option to use default bridges is only displayed if the necessary preferences are present. Another small consideration is that we (TBB developers) will probably not test Tor Launcher as a standalone XUL application because we will not be using it that way... so it is possible we will accidentally break something that is needed in that mode. Of course we will try not to do so. As long as Tor Launcher more or less sticks with its current design, and continues to keep away from stuff directly affecting Firefox (leaving that to Tor Button) and only do stuff related to starting/configuring/monitoring Tor processes, I expect very little problems due to your upstream changes. Does this look like your plan for the foreseeable future? Yes, although I leave it to Mike (in his role as TBB chief architect) to comment as well. Requirements may dictate a future change in direction, but for now the plan is for Torbutton and Tor Launcher to work together but maintain their distinct roles. -Mark ___ 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] Tor Launcher as a standalone XUL app in Tails
20/02/14 10:57, intrigeri wrote: anonym wrote (19 Feb 2014 19:14:40 GMT) : The primary profile can be used offline too. For instance, if a link in some GNOME notification is clicked, Iceweasel using the primary profile will be opened. We'd some how need to make Tor Launcher *not* run when the browser is opened while offline (start with `TOR_SKIP_LAUNCH`?). But then, if the browser was opened while offline and we then connect to a network (and we are in bridge mode), then the NM hook will want to start the already running browser with the envvar that will show Tor Launcher's network settings and then exit the browser. How can all this be achieved without creating a complete mess? OK. From the top of my head, two vaguely related notes: * We'll want to run Tor Launcher *only* when the user has ticked a checkbox in the Greeter, right? Or do we run it in all cases? It's been my assumption that we'll stick with the original checkbox in the Greeter plan. Of course, we could instead run it for each new connection (and always make sure `DisableNetwork` is set in torrc before we start Tor in the NM hook). It would actually make it harder for users that need bridge mode to make a mistake by accidentally logging in without checking the box (if there's a wired connection they're screwed by NM automatically connecting). When it comes to user experience, though, I'm not sure non-bridge users will be happy with this new, frequent pop-up that they have to deal with. In fact, it will train them to always click Connect so that they will screw themselves the time they actually need to add bridges. I think I prefer our original plan. Other opinions? * Note that we don't run the browser by default on network connection. See the wrapper in /usr/local/bin/iceweasel. Yes, I'm aware of this change. I suppose this also would have complicated things if we'd gone with the exit the browser approach. Was there anything else you had in mind by pointing this out, in case it got lost on 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] Tor Launcher as a standalone XUL app in Tails
20/02/14 16:35, Mark Smith wrote: On 2/19/14, 2:14 PM, anonym wrote: It sounds to me like the setting you are talking about does *not* have any direct effect on Firefox, only on Tor Launcher. To clarify, you are *not* setting e.g. `network.proxy.socks` (which Firefox itself uses), instead you are setting e.g. `extensions.torlauncher.xxx` (which Firefox itself doesn't use). Is this correct? (If so, we're happy -- see the end of this email.) Yes, I think that is correct. Excellent! It is a little difficult for Kathy and me to separate the two things because until now we have never thought about Tor Launcher running in a profile separate from the one where browsing will be done. Right but given the answer you gave me in the end of your email it should be pretty straight-forward. The standalone profile will only include whatever default settings are present in the Tor Launcher package itself, and the ones Tor Launcher sets during its operation (i.e. it will *not* include the TBB's settings *nor* stuff Firefox sets during its operation). However, since those are the settings you care about (currently, at least) you can reason about the standalone version in exactly the same way as when it's run as a Firefox extension. It's only when you use settings that are not exclusive to Tor Launcher that things may get problematic. This is also why we need to start tor with DisableNetwork=1 when the use default bridges option is enabled: so we can update the bridge configuration before tor starts its bootstrap process. See: https://trac.torproject.org/projects/tor/ticket/10418 [...] Will anything change with Tor Launcher's current design of immediately starting Tor and configure it to use the previous settings on all runs after the very first? [...] I tried to explain this in my last message but possibly I wasn't clear. We do not plan to show the network configuration wizard each time. The issue is that Tor Launcher needs to reconfigure the default bridges each time tor starts up. This is necessary because the default bridge addresses may change when TBB is upgraded (the addresses are stored as a series of hidden Tor Launcher preferences). Ah, now I get it. Thanks for you patience! :) I am not sure if the concept of default bridges is something you will want for Tails in the future or not. It doubt it. In Tails we care about the bridges being non-public to support the hide that you are using Tor use case as best we can. If we expose our users to a convenient option to use a public list of default bridges, then we put the users of that use case at risk. Therefore it'd be great if whatever GUI control you'll use for this option will be hidden (or at least disabled/greyed out) if the pre-supplied list of default bridges is empty/non-existent. That is already how things work. The option to use default bridges is only displayed if the necessary preferences are present. Great! Another small consideration is that we (TBB developers) will probably not test Tor Launcher as a standalone XUL application because we will not be using it that way... so it is possible we will accidentally break something that is needed in that mode. Of course we will try not to do so. As long as Tor Launcher more or less sticks with its current design, and continues to keep away from stuff directly affecting Firefox (leaving that to Tor Button) and only do stuff related to starting/configuring/monitoring Tor processes, I expect very little problems due to your upstream changes. Does this look like your plan for the foreseeable future? Yes, although I leave it to Mike (in his role as TBB chief architect) to comment as well. Requirements may dictate a future change in direction, but for now the plan is for Torbutton and Tor Launcher to work together but maintain their distinct roles. This is reassuring enough and welcome news! Now I truly feel confident that the standalone XUL approach is a perfect fit for Tails for now. Any ETA on when my patches can be reviewed? We plan to incorporate Tor Launcher in the next Tails release (0.23) which has its feature freeze on the 5th of March. If this could be upstreamed at the very latest the day before that (so there's time for us to package and test it), we'd be very happy. Of course, for that to happen the review would probably have to happen quite soon as I'm sure there'll be some back-and-forth with me revising the patches. In the worst case, if it's not upstreamed in time for our freeze, we can of course ship a patched Tor Launcher for this release and have them upstreamed for the next release or so, so it's not an imminent, hard requirement. Also, see attached files for a new patch set. From now on I won't rebase the patches any more in order to ease your review process. For the record, I've tested the patched Tor Launcher successfully both as a Firefox extension, and a standalone XUL application. Cheers! From
Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails
On 2/18/14, 1:08 PM, anonym wrote: Ah, now I get it, thanks! I must admit that even though I read this I completely missed the actual point. I still thought we were going to try the standalone XUL approach, and that's what I did (as indicated by the new subject line in this thread). Sorry for the confusion. Luckily I think this misunderstanding may be good in the end as it made me investigate the standalone approach: TL;DR: the standalone XUL application idea (whose difficulty has not been asserted) was superseded by the exit the browser right after the Tor Lancher config screens, if a given envvar is set one, since it seemed way easier, and good enough for us. TL;DR: I think the standalone approach is better, and like to switch it. The main reason we proposed the exit browser after configuration solution was because we were not sure how much work it would be to create a standalone XUL app. But you have already done the work. The downside I see is that you will need to ship (and maintain) XULRunner. But maybe you already need to do that for other reasons. Some notes on exit the browser vs standalone XUL approaches: ... * When it comes to upstream maintenance, the exit the browser and standalone XUL approaches are pretty similar, at least as long as Tor Launcher only deals with starting/configuring Tor, and do not interact with Firefox (e.g. add something to `prefs.js` that's relevant for Firefox, or whatever). Tor Launcher maintainers, is this the plan for the foreseeable future? To support a pluggable transports (PT) Tor Browser bundle, we have added an option to configure a default set of bridges. That option requires setting preferences inside the browser so that Tor Launcher knows to reconfigure the default bridges each time the browser is started (we need to set the bridge configuration each time because they originate from hidden Tor Launcher preferences which may be updated when a new version of TBB is installed). This is also why we need to start tor with DisableNetwork=1 when the use default bridges option is enabled: so we can update the bridge configuration before tor starts its bootstrap process. See: https://trac.torproject.org/projects/tor/ticket/10418 I am not sure if the concept of default bridges is something you will want for Tails in the future or not. Another small consideration is that we (TBB developers) will probably not test Tor Launcher as a standalone XUL application because we will not be using it that way... so it is possible we will accidentally break something that is needed in that mode. Of course we will try not to do so. -- Mark Smith Pearl Crescent http://pearlcrescent.com/ ___ 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] Tor Launcher as a standalone XUL app in Tails
Hi, anonym wrote (18 Feb 2014 18:08:01 GMT) : TL;DR: I think the standalone approach is better, and like to switch it. After reading the following (but not the last email from Mark yet), I now concur. Some notes on exit the browser vs standalone XUL approaches: [...] * The way I understand the exit the browser approach is that we'd have Tor Launcher installed as an Iceweasel extension. However, having it intalled in our default Iceweasel profile will not be pretty so we'll have to generate yet another profile, with the added complexity and maintaince burden of that. I don't see the downsides of having Tor Launcher installed as an extension in our primary browsing profiles. I guess that's not a decisive point anyway. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ 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] Tor Launcher as a standalone XUL app in Tails
19/02/14 15:14, Mark Smith wrote: On 2/18/14, 1:08 PM, anonym wrote: TL;DR: I think the standalone approach is better, and like to switch it. The main reason we proposed the exit browser after configuration solution was because we were not sure how much work it would be to create a standalone XUL app. Completely understandable. I certainly thought the standalone approach would be much more problematic than it turned out to be. :) [...] Some notes on exit the browser vs standalone XUL approaches: ... * When it comes to upstream maintenance, the exit the browser and standalone XUL approaches are pretty similar, at least as long as Tor Launcher only deals with starting/configuring Tor, and do not interact with Firefox (e.g. add something to `prefs.js` that's relevant for Firefox, or whatever). Tor Launcher maintainers, is this the plan for the foreseeable future? To support a pluggable transports (PT) Tor Browser bundle, we have added an option to configure a default set of bridges. That option requires setting preferences inside the browser so that Tor Launcher knows to reconfigure the default bridges each time the browser is started (we need to set the bridge configuration each time because they originate from hidden Tor Launcher preferences which may be updated when a new version of TBB is installed). It sounds to me like the setting you are talking about does *not* have any direct effect on Firefox, only on Tor Launcher. To clarify, you are *not* setting e.g. `network.proxy.socks` (which Firefox itself uses), instead you are setting e.g. `extensions.torlauncher.xxx` (which Firefox itself doesn't use). Is this correct? (If so, we're happy -- see the end of this email.) This is also why we need to start tor with DisableNetwork=1 when the use default bridges option is enabled: so we can update the bridge configuration before tor starts its bootstrap process. See: https://trac.torproject.org/projects/tor/ticket/10418 [Note: The reason I'm continuing this part of the discussion is not because I think it will be especially relevant for Tails directly but it does help me to better understand where Tor Launcher is going in the future so I can assess if Tor Launcher in Tails is a long-term solution or not. It may be that I'm just wasting everyone's time here being confused and speculating about a future change that I don't know the exact details of, so we may want to just drop it. :)] Will anything change with Tor Launcher's current design of immediately starting Tor and configure it to use the previous settings on all runs after the very first? Otherwise I don't see the relevance of setting `DisableNetwork=1` beyond the first run; if the use default bridges option was chosen on first run, bridges will be written into torrc, which makes `DisableNetwork=1` redundant. However, if the design does change, e.g. that you show the network settings on *each* run, with `DisableNetwork=1` set (highly relevant now since the user may have chosen connect in the clear in the previous run), then I don't see why you thought this new behaviour would be incompatible earlier patch (0002-Always-open-network-settings-if-DisableNetwork-is-se.patch). I am not sure if the concept of default bridges is something you will want for Tails in the future or not. It doubt it. In Tails we care about the bridges being non-public to support the hide that you are using Tor use case as best we can. If we expose our users to a convenient option to use a public list of default bridges, then we put the users of that use case at risk. Therefore it'd be great if whatever GUI control you'll use for this option will be hidden (or at least disabled/greyed out) if the pre-supplied list of default bridges is empty/non-existent. Another small consideration is that we (TBB developers) will probably not test Tor Launcher as a standalone XUL application because we will not be using it that way... so it is possible we will accidentally break something that is needed in that mode. Of course we will try not to do so. As long as Tor Launcher more or less sticks with its current design, and continues to keep away from stuff directly affecting Firefox (leaving that to Tor Button) and only do stuff related to starting/configuring/monitoring Tor processes, I expect very little problems due to your upstream changes. Does this look like your plan for the foreseeable future? [Sorry for essentially repeating my question from earlier, but a straight answer to this question would help immensely for assessing the viability of Tails' new plan w.r.t. Tor Launcher.] 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] Tor Launcher as a standalone XUL app in Tails
19/02/14 15:40, intrigeri wrote: Hi, anonym wrote (18 Feb 2014 18:08:01 GMT) : TL;DR: I think the standalone approach is better, and like to switch it. After reading the following (but not the last email from Mark yet), I now concur. Excellent! Then I'll proceed on this path. To be able to work on this more efficiently (well, faster feedback you all) I think I'll start with a quick-and-dirty POC branch in Tails where I'll just include Tor Launcher via config/chroot_local-includes to avoid the packaging (that part will be nuked from the history before merging). This way I can work on the Tails integration and Debian packaging of Tor Launcher (which I may ask you about some best practices) in parallel. Some notes on exit the browser vs standalone XUL approaches: [...] * The way I understand the exit the browser approach is that we'd have Tor Launcher installed as an Iceweasel extension. However, having it intalled in our default Iceweasel profile will not be pretty so we'll have to generate yet another profile, with the added complexity and maintaince burden of that. I don't see the downsides of having Tor Launcher installed as an extension in our primary browsing profiles. I guess that's not a decisive point anyway. For whatever it's worth (since you already seem to be convinced for other reasons) here's one example on why I think it's messy, and I think it suggests that there are deeper reasons why the browser and Tor controller should be separate among our assumptions, and in Tails' design: The primary profile can be used offline too. For instance, if a link in some GNOME notification is clicked, Iceweasel using the primary profile will be opened. We'd some how need to make Tor Launcher *not* run when the browser is opened while offline (start with `TOR_SKIP_LAUNCH`?). But then, if the browser was opened while offline and we then connect to a network (and we are in bridge mode), then the NM hook will want to start the already running browser with the envvar that will show Tor Launcher's network settings and then exit the browser. How can all this be achieved without creating a complete mess? 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] Tor Launcher as a standalone XUL app in Tails [Was: Tor Launcher extension]
Hi, anonym wrote (18 Feb 2014 01:07:07 GMT) : Sorry, but I don't understand the exit the browser [...] part. In the way we intend to use the Tor Launcher in Tails there will be no browser as it will run as a standalone XUL application. There seems to be some amount of misunderstanding here. As suggested earlier privately, you really want to read the beginning of this thread. TL;DR: the standalone XUL application idea (whose difficulty has not been asserted) was superseded by the exit the browser right after the Tor Lancher config screens, if a given envvar is set one, since it seemed way easier, and good enough for us. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ 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] Tor Launcher as a standalone XUL app in Tails
18/02/14 10:56, intrigeri wrote: Hi, anonym wrote (18 Feb 2014 01:07:07 GMT) : Sorry, but I don't understand the exit the browser [...] part. In the way we intend to use the Tor Launcher in Tails there will be no browser as it will run as a standalone XUL application. There seems to be some amount of misunderstanding here. As suggested earlier privately, you really want to read the beginning of this thread. I assume the following quote is what you are talking about: 14/01/14 17:09, Kathleen Brade wrote (in email with Message-ID 52d5614d.3090...@pearlcrescent.com): Here is another idea: What if Tor Launcher presented its initial configuration dialogs and then exited after the user clicked Connect? Ah, now I get it, thanks! I must admit that even though I read this I completely missed the actual point. I still thought we were going to try the standalone XUL approach, and that's what I did (as indicated by the new subject line in this thread). Sorry for the confusion. Luckily I think this misunderstanding may be good in the end as it made me investigate the standalone approach: TL;DR: the standalone XUL application idea (whose difficulty has not been asserted) was superseded by the exit the browser right after the Tor Lancher config screens, if a given envvar is set one, since it seemed way easier, and good enough for us. TL;DR: I think the standalone approach is better, and like to switch it. Some notes on exit the browser vs standalone XUL approaches: * Just to be clear: the code needed for the don't start, only configure Tor use case is completely independent either approach. * The *only* thing required to run Tor Launcher as a standalone XUL application is an application.ini and the correct invocation of xulrunner. In particular, no code changes are required inside Tor Launcher's logic. * At least the previous point is true for the Tails use case. To make standalone Tor Launcher support *starting* *and* *owning* the Tor process as well (i.e. without `TOR_CONFIGURE_ONLY=1`), I think some more work is needed, since owning the Tor process means that it'll terminate when Tor Launcher closes (i.e. immediately after it has configured Tor in the standalone case). Since we don't need it, I guess we wouldn't care, but fixing it should be pretty simple for those that do. * Actually the exit the browser approach will require one piece of extra code, namely to exit the browser at the appropriate time if `TOR_CONFIGURE_ONLY=1`. Actually, overloading that option with this additional behaviour is pretty ugly and highly Tails-specific (non-Tails users may want to set that option to configure their system-wide Tor *and* have a browser afterwards). It'd make more sense with yet another option, like `NO_BROWSER=1` or something similarly weird. Otherwise we might just as well bake all Tails-specific stuff into a `RUNNING_IN_TAILS=1`. * When it comes to upstream maintenance, the exit the browser and standalone XUL approaches are pretty similar, at least as long as Tor Launcher only deals with starting/configuring Tor, and do not interact with Firefox (e.g. add something to `prefs.js` that's relevant for Firefox, or whatever). Tor Launcher maintainers, is this the plan for the foreseeable future? * When it comes to Debian packaging, both are trivial to package. I suppose that, if anything, Debian is more likely to ever package the Firefox extension, but even that seems unlikely to me at this point. Hence I guess we (Tails) will be effectively responsible for it, so there's nothing in favour of either approach here then. * The way I understand the exit the browser approach is that we'd have Tor Launcher installed as an Iceweasel extension. However, having it intalled in our default Iceweasel profile will not be pretty so we'll have to generate yet another profile, with the added complexity and maintaince burden of that. * Relating to the previous point, nothing extra is required for the standalone Tor Launcher to run it as a separate profile (starting it will automatically create a profile in `.torproject/tor-launcher`). Conclusion: if my analysis above is correct, and my assertions/questions are the way I expect, then the standalone XUL approach is in fact cleaner, simpler, more flexible, more portable (outside the Tails context) and more maintainable than the exit the browser one. I can see no disadvantage with it, now that the research has been done. Therefore I think we should change the old plan and go with the standalone XUL application approach instead. 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] Tor Launcher as a standalone XUL app in Tails [Was: Tor Launcher extension]
11/02/14 20:17, Mark Smith wrote: On 2/11/14, 11:23 AM, anonym wrote: 11/02/14 02:37, anonym wrote: # Tor Launcher in Tails All in all, not much is necessary to make Tor Launcher able to *only* control (as opposed to own, i.e. control + Tor is started by the controller, and Tor exits with the controller) a system-wide Tor instance: src/application.ini | 13 + src/chrome/locale/en/torlauncher.properties |1 + src/components/tl-process.js| 32 ++-- 3 files changed, 40 insertions(+), 6 deletions(-) Thanks for working on this. Thank you for providing an alternative to the now-abandoned Vidalia! And sorry for thinking that Mark was a mistaken Mike in my first post in this thread -- I just didn't see any mention of Mark in the Git history. :S See attached files for a POC. Essentially what my changes do is to separate the starting Tor and control Tor code, and skip the former if `extensions.torlauncher.start_tor` is `false`, or if `TOR_SKIP_LAUNCH` is `1`. The old behaviour of those options is to do absolutely nothing w.r.t. starting/communicating with Tor, so I suppose they were only used for debugging. IMHO this new behaviour is better than introducing `TOR_CONFIGURE_ONLY`, as suggested. If the old behaviour is still needed we can instead introduce a new option, like `IGNORE_TOR` or whatever. I think we need to preserve the existing behavior. There are people who are using TOR_SKIP_LAUNCH and the extensions.torlauncher.start_tor preference, and I don't think we should break things for them. What use cases are they trying to achieve by using Tor Launcher like that? Is it for just starting the browser in the TBB by making Tor Launcher do (more or less) nothing? We picked the name TOR_CONFIGURE_ONLY for the new behavior because we thought Tor Launcher would need to exit the browser after the settings wizard finished. If that is not the case, a name like TOR_CONTROL_ONLY would be better. Sorry, but I don't understand the exit the browser [...] part. In the way we intend to use the Tor Launcher in Tails there will be no browser as it will run as a standalone XUL application. ... We can skip the `TOR_SKIP_LAUNCH` and `TOR_CONTROL_PORT` environment variables by instead using the corresponding settings in `prefs.js`, but there is no option corresponding to `TOR_CONTROL_COOKIE_AUTH_FILE` although a `extensions.torlauncher.control_cookie_path` should be easy to add. This is only relevant if we prefer to use proper settings instead of environment variables. Is there an advantage to avoiding environment variables? They are already implemented and they work ;) Not really. In fact it may just increase our maintenance burden since keeping our own `prefs.js` will also require us to keep it in-sync with your upstream changes. # Problem: settings persistence with a system-wide Tor setup In Vidalia, settings configured by the user (like `bridge ...`, `HTTPProxy ...`, etc) persist by being saved in Vidalia's config (well, I think Vidalia first tries to write the settings to torrc via `SAVECONF` and falls back to this if it fails, which it does in Tails), and they are restored as soon as Vidalia establishes control of Tor. In Tails' current, experimental bridge mode, the obvious race condition is dealt with by adding an invalid bridge, which effectively emulated the `DisableNetwork` option (in combination with our custom Vidalia patches). In Tor Launcher, settings configured by the user are saved directly in torrc (via `SAVECONF`), which doesn't fit very well in the Tails context. With my changes applied, the changes are simply lost whenever Tor restarts, which will happened for a number of reasons, e.g. for each new network connection. This is a fundamental issue that my changes doesn't currently deal with, and I'm unsure how to proceed. Below are some thoughts on our options: ... I admit that I do not understand everything about the Tails architecture. It sounds like users can write to the browser's (or XULRunner's) prefs.js but not to torrc? Is this restriction present to improve security or for a different reason? In order to lessen the damage possible by compromising certain users we do (at least) the following: * The system-wide Tor process runs under the `debian-tor` user. * The torrc used by Tor is only writeable by `root`. * Tor controllers are run under yet another user (currently called `vidalia` since that's our current controller). When we designed Tor Launcher, we tried hard to only have Tor settings stored in one place (torrc). I don't like the idea of caching all of the Tor settings as Tor Launcher preferences, but maybe that is the only viable solution given your architecture. I understand this, and I think the Vidalia developers suffered a bit from supporting that. Something we Tails developers may want
[Tails-dev] Tor Launcher as a standalone XUL app in Tails [Was: Tor Launcher extension]
11/02/14 02:37, anonym wrote: 10/02/14 23:01, intrigeri wrote: Hi, Kathleen Brade wrote (10 Feb 2014 15:17:23 GMT) : On 2/9/14, 10:21 AM, intrigeri wrote: So, now that we agree on something that would satisfy our needs, what's the plan? Has anyone allocated time to implement this? If someone is planning to do it, is there any ETA? I think this is easy to add to Tor Launcher; Mark and I can probably do it in the next couple of days. Awesome! anonym, given you'll be working on bridges support soon, may you please have a look at this idea ASAP, and evaluate how well it could replace our initial plan? From my PoV it looks just great, compared to the initial setup being done in Vidalia, but I might have missed something. I did some research into this earlier today and have a working, standalone POC that can deal with system-wide Tor instances (but it is incomplete in some ways that require further discussion). I'm way too tired at the moment to do the write up, but I will do it after I've got some sleep. In other words, Mark (Mike?), Kathleen and others: please don't duplicate work by looking into this until I've posted my results. Here's my results: # Tor Launcher in Tails All in all, not much is necessary to make Tor Launcher able to *only* control (as opposed to own, i.e. control + Tor is started by the controller, and Tor exits with the controller) a system-wide Tor instance: src/application.ini | 13 + src/chrome/locale/en/torlauncher.properties |1 + src/components/tl-process.js| 32 ++-- 3 files changed, 40 insertions(+), 6 deletions(-) See attached files for a POC. Essentially what my changes do is to separate the starting Tor and control Tor code, and skip the former if `extensions.torlauncher.start_tor` is `false`, or if `TOR_SKIP_LAUNCH` is `1`. The old behaviour of those options is to do absolutely nothing w.r.t. starting/communicating with Tor, so I suppose they were only used for debugging. IMHO this new behaviour is better than introducing `TOR_CONFIGURE_ONLY`, as suggested. If the old behaviour is still needed we can instead introduce a new option, like `IGNORE_TOR` or whatever. # How to start as a stand-alone application in Tails To test it, add a firewall exception for port 9051 to the `vidalia` user in `/etc/ferm/ferm.conf`, and run: git clone https://git.torproject.org/tor-launcher.git cd tor-launcher # apply attached patches sudo -u vidalia TOR_SKIP_LAUNCH=1 TOR_CONTROL_PORT=9051 TOR_CONTROL_COOKIE_AUTH_FILE=/var/run/tor/control.authcookie xulrunner-17.0 src/application.ini -purgecaches For the bridge mode behaviour, set `DisableNetwork 1` in torrc first. (The `-purgecaches` is useful for clearing the XUL runner cache; otherwise ignore changes made to the source files (at least the `.js` files) are ignored after the first run. In other words, this is only relevant for development and can otherwise be skipped.) We can skip the `TOR_SKIP_LAUNCH` and `TOR_CONTROL_PORT` environment variables by instead using the corresponding settings in `prefs.js`, but there is no option corresponding to `TOR_CONTROL_COOKIE_AUTH_FILE` although a `extensions.torlauncher.control_cookie_path` should be easy to add. This is only relevant if we prefer to use proper settings instead of environment variables. # Problem: settings persistence with a system-wide Tor setup In Vidalia, settings configured by the user (like `bridge ...`, `HTTPProxy ...`, etc) persist by being saved in Vidalia's config (well, I think Vidalia first tries to write the settings to torrc via `SAVECONF` and falls back to this if it fails, which it does in Tails), and they are restored as soon as Vidalia establishes control of Tor. In Tails' current, experimental bridge mode, the obvious race condition is dealt with by adding an invalid bridge, which effectively emulated the `DisableNetwork` option (in combination with our custom Vidalia patches). In Tor Launcher, settings configured by the user are saved directly in torrc (via `SAVECONF`), which doesn't fit very well in the Tails context. With my changes applied, the changes are simply lost whenever Tor restarts, which will happened for a number of reasons, e.g. for each new network connection. This is a fundamental issue that my changes doesn't currently deal with, and I'm unsure how to proceed. Below are some thoughts on our options: * No settings persistence for system-wide Tor instances: While simple to implement, it's inconsistent with how it works compared to when Tor Launcher starts Tor, which may confuse users familiar with TBB. And it's annoying; all bridges have to be re-entered each time the wireless dies, etc. Also it's inconsistent with how it works in Vidalia, for whatever that's worth. * Vidalia-like settings persistence: I suppose we could save the settings as `extensions.torlauncher.torconf_httpproxy =
Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails [Was: Tor Launcher extension]
On 2/11/14, 11:23 AM, anonym wrote: 11/02/14 02:37, anonym wrote: # Tor Launcher in Tails All in all, not much is necessary to make Tor Launcher able to *only* control (as opposed to own, i.e. control + Tor is started by the controller, and Tor exits with the controller) a system-wide Tor instance: src/application.ini | 13 + src/chrome/locale/en/torlauncher.properties |1 + src/components/tl-process.js| 32 ++-- 3 files changed, 40 insertions(+), 6 deletions(-) Thanks for working on this. See attached files for a POC. Essentially what my changes do is to separate the starting Tor and control Tor code, and skip the former if `extensions.torlauncher.start_tor` is `false`, or if `TOR_SKIP_LAUNCH` is `1`. The old behaviour of those options is to do absolutely nothing w.r.t. starting/communicating with Tor, so I suppose they were only used for debugging. IMHO this new behaviour is better than introducing `TOR_CONFIGURE_ONLY`, as suggested. If the old behaviour is still needed we can instead introduce a new option, like `IGNORE_TOR` or whatever. I think we need to preserve the existing behavior. There are people who are using TOR_SKIP_LAUNCH and the extensions.torlauncher.start_tor preference, and I don't think we should break things for them. We picked the name TOR_CONFIGURE_ONLY for the new behavior because we thought Tor Launcher would need to exit the browser after the settings wizard finished. If that is not the case, a name like TOR_CONTROL_ONLY would be better. ... We can skip the `TOR_SKIP_LAUNCH` and `TOR_CONTROL_PORT` environment variables by instead using the corresponding settings in `prefs.js`, but there is no option corresponding to `TOR_CONTROL_COOKIE_AUTH_FILE` although a `extensions.torlauncher.control_cookie_path` should be easy to add. This is only relevant if we prefer to use proper settings instead of environment variables. Is there an advantage to avoiding environment variables? They are already implemented and they work ;) # Problem: settings persistence with a system-wide Tor setup In Vidalia, settings configured by the user (like `bridge ...`, `HTTPProxy ...`, etc) persist by being saved in Vidalia's config (well, I think Vidalia first tries to write the settings to torrc via `SAVECONF` and falls back to this if it fails, which it does in Tails), and they are restored as soon as Vidalia establishes control of Tor. In Tails' current, experimental bridge mode, the obvious race condition is dealt with by adding an invalid bridge, which effectively emulated the `DisableNetwork` option (in combination with our custom Vidalia patches). In Tor Launcher, settings configured by the user are saved directly in torrc (via `SAVECONF`), which doesn't fit very well in the Tails context. With my changes applied, the changes are simply lost whenever Tor restarts, which will happened for a number of reasons, e.g. for each new network connection. This is a fundamental issue that my changes doesn't currently deal with, and I'm unsure how to proceed. Below are some thoughts on our options: ... I admit that I do not understand everything about the Tails architecture. It sounds like users can write to the browser's (or XULRunner's) prefs.js but not to torrc? Is this restriction present to improve security or for a different reason? When we designed Tor Launcher, we tried hard to only have Tor settings stored in one place (torrc). I don't like the idea of caching all of the Tor settings as Tor Launcher preferences, but maybe that is the only viable solution given your architecture. ... If we can agree on what the right thing to do with all this is, and I haven't missed anything big, I feel confident that we can drop Vidalia and have bridge mode implemented using Tor Launcher in Tails 0.23. Kathy and I will need to review your patches in more detail, but one comment is that I don't think Tor Launcher should open the network settings wizard whenever DisableNetwork=1. In fact, to support PTs we are adding a Use Default Bridges option which will require that Tor Launcher always start Tor with DisableNetwork=1 (so that the correct bridge configuration can be set before Tor touches the network). Can you instead ensure that the extensions.torlauncher.prompt_at_startup pref is set to 'true' before starting Tor Launcher? -- Mark Smith Pearl Crescent http://pearlcrescent.com/ ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
