Re: [Tails-dev] [tor-qa] Tor Browser 7.5 is ready for testing
On 1/19/18 10:54 AM, Georg Koppen wrote: > Hi all! > > Tor Browser 7.5 is ready for testing. Bundles can be found on: > > https://people.torproject.org/~gk/builds/7.5-build3/ > ... Similar to what I did with the 8.0 alpha builds, I did a little testing of the 7.0.11 built-in updater on macOS using my own staging server. I did not find any problems with 7.0.11 to 7.5 incremental or full updates, and an "in place" update of Tor Browser 7.5 to 7.5 also worked correctly. -- Mark Smith Pearl Crescent http://pearlcrescent.com/ signature.asc Description: OpenPGP 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] [tbb-dev] future of tor-launcher? - Firefox XPCOM / XUL based add-ons deprecation
On 1/10/17 5:27 AM, anonym wrote: > Michael Carbone: >> The move away from XUL could be an opportunity to address this by >> building a more generic solution that could be used by the increasing >> number of tor-powered applications/environments, such as onionshare, >> ricochet, tails, qubes, subgraph, etc., in addition to tor browser and >> tor messenger. We talked about this a little bit yesterday during our Tor Browser team meeting on #tor-dev. The tight integration of Tor Launcher within the browser has been a big win for both user experience and for maintenance of the launcher and configuration code. Our current plan for Tor Browser is to migrate Torbutton and Tor Launcher to the WebExtensions APIs, extending and adding new APIs as needed (and hopefully Mozilla will help us). See https://trac.torproject.org/projects/tor/ticket/17248. > Indeed! In Tails we have a ticket and blueprint tracking something like > this: > > https://labs.riseup.net/code/issues/10491 > https://tails.boum.org/blueprint/network_connection/ > > Of course, our configuration tool would also include OS-level stuff, but > I guess SubgraphOS/Qubes/Whonix would also be interested in that. At > least it'd be nice if code could be shared (e.g. we can import the Tor > configuration parts via a module and use the same in our application). > Bonus if it's written in Python, building on the ecosystem of > Tor-related project we already have there (primarily stem). > > I expect that some Tails people attending the Tor dev meeting in March > might be interested in discussing this. I think it is definitely worthwhile to talk more about this. If code cannot be shared, at least UI designs can be. It is also worth noting that Yawning created a new launcher/updater for Linux as part of his Sandboxed Tor Browser Project (it uses go, Gtk+ 3, and libnotify). https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux -- Mark Smith Pearl Crescent http://pearlcrescent.com/ signature.asc Description: OpenPGP 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] [tbb-dev] future of tor-launcher? - Firefox XPCOM / XUL based add-ons deprecation
On 1/10/17 5:18 AM, anonym wrote: > In Tails we run Tor Launcher as a stand-alone XUL application. Last I > checked it was not clear whether this would still be supported by > Firefox + WebExtensions. Do you know anything more about this? Unfortunately, I do not know anything about Mozilla's plans in regard to standalone XUL applications. Currently Tails is using the firefox -app feature, correct? In the long run, I expect Mozilla to stop using XUL entirely and to migrate to HTML-based UI even inside Firefox. Although it will take them a long time to make that transition, I could see them dropping support for standalone XUL applications relatively soon. I don't expect WebExtensions to support a standalone app mode, although for your purposes it might be acceptable to start the browser with TOR_CONFIGURE_ONLY=1. I guess there are some differences in terms of how much Firefox code is executed as well as loss of a custom icon though. -- Mark Smith Pearl Crescent http://pearlcrescent.com/ signature.asc Description: OpenPGP 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] Make Tor Binary location configurable in Tor Launcher?
On 6/17/14 4:42 PM, anonym wrote: 17/06/14 17:44, Mike Perry wrote: While reviewing that patch, it occurred to me that it might be useful to make the path to the Tor binary configurable in a pref, rather than hardcoding the depth and pieces of the directory structure in the code and launching logic. You've supported this for a while now via the extensions.torlauncher.*_path prefs and the code is still there (see beginning of _getTorFile). So should I take it that this is broken now, at least for the tor executable? Any way... I hope it is not broken. Last time I tried it, the pref override was working. Regardless, this does not sound like an issue for Tails. -- Mark Smith Pearl Crescent, LLC 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
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
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 [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
