May 2017 - tbb-dev - lists.torproject.org

Re: [tbb-dev] [tor-dev] RFC: porting torbrowser (was: Re: GNU Guix and Tor Browser Packaging)
by ng0 09 Mar '18

09 Mar '18

Hi, It seems as if tbb-dev(a)lists.torproject.org is the list which would be more appropriate. If the 7 days without a reaction are simply due to the holidays in some countries, it's my mistake. If you need internal discussion about this to respond appropriately, let me know that you are reviewing this message at all. I have no expectation for "neoliberal optimized" reply times. Thanks. ng0 transcribed 7.9K bytes: > Hi folks, > > as your trademarks team / person suggested to me I get in touch with the > dev team of torproject. While I'm more involved in GNUnet, I work at the > intersection of projects. Currently this means I'm involved in system > integration. At Guix we are interested in working closer with projects > like tor, TAILS, Whonix and the like. Porting torbrowser is not only in > the interest of the Guix community but also in the interest of Wonix who > recently expressed interest in selectively using Guix for their work. > For me as maintainer of the system (in development) pragmaOS it also > means that we can decide between icecat OR torless torbrowser for > proxied GNUnet connections. > > I'm interested in your response to the actions listed below and wether > you think this will still qualify as torbrowser or what other option you > propose for us at Guix to use. "Option" here means that I am not sure > what other graphical theme you have for versions of the browser which do > not use the trademark when they can (logically) also not use the firefox > trademarks. > I would reflect in the description of the package that it is not > torbrowser but a reconstruction of the way torbrowser is build, tracking > upstream as closely as possible while removing (list of features which > were removed goes here). > This can be compared to what the inoffical Gentoo maintainer does in the > .ebuild file here: > https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/ > > My request here is just in the position as a contributor to Guix, not > for pragmatique (the project which works on pragmaOS etc), Whonix, > GNUnet or any other project I mentioned before. > > Thanks in advance. Now the content I've been talking about: > > It looks like the changes I need to make to torbrowser are not so > grave at all. Someone pointed me to the gnu-linux-libre(a)nongnu.org list > to reach out to other FSDG systems. > The thread can be reviewed here: > https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-03/msg00002.html > > Basically: > > I will need to discourage Mozilla leftovers: > - the mozilla addon service will be overwritten, in other words: > Where you would find https://addons.mozilla.org/ at "Preferences > AddOns" > it will be replaced by the thing Icecat points to. Longterm plan is > to offer firefox extensions native through "guix package -i > youraddonnamehere". > > Privacy / Tracking reasons: > - Firefox "Sync" will be disabled. > - Google will be removed from the search plugins if I understood the > procedure correctly (at least it is not in Icecat) > > A question directly for torbrowser team: > - about:license does not list licenses the torbrowser project uses, only > firefox. Why? > > DRM > - Luke from parabola mentioned that drm has been enabled in recent > versions of torbrowser. This needs to be removed aswell. > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/vendor.js#n23 > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/mozconfig#n39 > https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/fire… > > ng0 transcribed 3.4K bytes: > > bancfc(a)openmailbox.org transcribed 1.9K bytes: > > > There is a serious Tor Browser packaging effort [3][4] being done by ng0 > > > (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports > > > > Eh, now that the cat is out of the bag (cat's don't belong into bags > > anyway), I think I have to do this now and not on my own conditions. > > > > Hi! > > > > As I told bancfc somewhere else, I've had a short contact with the > > trademarks team of torproject. I will get back to you when someone was > > able to identify issues in torbrowser which might lead to modifications > > of torbrowser (for more details I just hope trademarks(a)tp.o can > > communicate it to you) because all packaged software which is included > > in upstream of Guix (master) must follow the GNU Free System > > Distribution Guidelines. > > I hope that I have to make as little modifications as possible as I > > I am aware that the fingerprint of the browser could change depending on > > the kind of changes. > > > > I hope to get back to this task in about 3 weeks, right now I'm busy > > with getting more documentation done for another project. > > > > > transactional upgrades and roll-backs, unprivileged package management, > > > per-user profiles and most importantly reproducible builds. I have checked > > > with Guix's upstream and they are working on making a binary mirror > > > available over a Tor Hidden Service. [2] Also planned is resilience [2] to > > > the attack outlined in the TUF threat model. [1] > > > > > > Back to the topic of Tor Browser packaging. While there are good reasons for > > > Debian's pakaging policies they make packaging of fast evolving software > > > (and especially with TBB's reliance on a opaque binary VM for builds) > > > impractial. Both we and Micah have been doing a good effort to automate > > > downloading and validating TBB but I still believe its a maintenance burden > > > and Guix may be a way out of that for Linux distros in general. > > > > > > What are your thoughts on this? > > > > > > > > > > > > > > > > > > *** > > > > > > [0] https://www.gnu.org/software/guix/ > > > [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md > > > [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html > > > [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html > > > [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html > > > _______________________________________________ > > > tor-dev mailing list > > > tor-dev(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- > PGP and more: https://people.pragmatique.xyz/ng0/ > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- PGP and more: https://people.pragmatique.xyz/ng0/

4 8

Re: [tbb-dev] So, about the Linux sandbox in the long term?
by Hans-Christoph Steiner 07 Jun '17

07 Jun '17

Tom Ritter tom at ritter.vg wrote: > On 30 May 2017 at 07:45, Yawning Angel <yawning at schwanenlied.me> wrote: >> On Tue, 30 May 2017 11:04:00 +0000 >> Georg Koppen <gk at torproject.org> wrote: >>> Oh, and it is not only Linux, OSX and Windows we need to take into >>> account for planning the future for our sandboxing work. Android is >>> coming later this year as a platform for Tor Browser as well. So, if >>> we start thinking about the need for rewriting parts of what we >>> include into Tor Browser now (and what is planned to get included >>> into Tor Browser for Mobile) Android requirements for sandboxing >>> should be considered, too. >> >> Oh boy. I don't see AppArmor working at all, though this depends >> on the kernel. seccomp + namespaces might work, though this also >> depends on how the kernel is built. >> >> Doesn't the OS handle containerization and secure updates? Are we >> doing the play store thing? Is tor-launcher even relevant on that >> platform, or is Orbot going to continue to handle all of that? >> >> (I suspect that Android will end up remaining as the redheaded step >> child, depending on what path makes sense for the real computer >> platforms.) > > For updates, I suspect that the Google Play and F-Droid (and maybe a > custom Tor Project FDroid repo) are the way to go, and supporting > anything else would be too much trouble. See also > https://lists.mayfirst.org/pipermail/guardian-dev/2017-May/005278.html > I haven't looked closely at how FDroid or a custom fdroid repo works > though. > > The OS does handle containerization, thankfully. There are some IPC > mechanisms we should investigate (sending URL intents for example). > But the sandboxing options on Android are probably much more limited > than Desktop linux. I don't know of anyone who's played around with it > actually. I think the current plan is to integrate tor into the > Browser app; and not use Orbot - but I'm not sure where that would let > us do any network-lockdown sandboxing that might be possible. > > I am not certain if an Android app has permission to rewrite itself. > We would need to investigate to be certain that this can only be done > by the updater. > > Definitely a lot of questions here... Android is a very different OS than all the desktops. GNU/Linux, OSX and Windows are much more similar to each other than to Android. Android is also the most popular computing platform in the world, so its worth investing it. More users and more page views than Windows. Given the desire for stronger sandboxing, it could make sense to keep tor in something like Orbot, which is installed separately. That means its isolated from the browser part with all the Android tricks. Things like CopperheadOS make that sandboxing even stronger. As for Android apps updating their own code, it is possible, and it is occasionally done. It is considered a bad practice, and Google has been gradually locking that down over time. Android already provides a solid install procedure, at best, I think it would be a waste of time to build a custom in-app updater to replace that. For example, that will break nice security properties like the code being installed read-only even to the app itself. .hc (I'm not on tbb-dev, so keep me CC'ed). -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

4 7

So, about the Linux sandbox in the long term?
by Yawning Angel 05 Jun '17

05 Jun '17

Hello, I'm curious what the long term plans for the sandbox are, because as it stands and unless I hear differently, the current status is something along the lines of: * I will poke at it if something really bothers me, and I have the time. * I will fix bugs if something breaks for me. * Someone submits well written patches, which I will review and merge, if I like the patches. nb: The "if I like the patches" clause is so that it doesn't turn into a lisp interpreter masquerading as a text editor, that also happens to launch a browser. This is also largely moot, check the git history to see why. A few months ago I sent a detailed list of what remains to be done, and a time estimate assuming someone was working full time. However, to be frank, I am increasingly uncertain as to if doing the improvements (beyond the security/hardening ones) makes any sense because: * It is my belief that the current Tor Browser architecture is diametrically opposed to what is required for proper containerization. While `sandboxed-tor-browser` makes a valiant effort, the approach is hampered and limited by what it has to work with, and it will forever be stuck reimplementing large chunks of functionality from firefox, torbutton, and tor-launcher. * I am a terrible UI programmer, and looking ahead, it will become increasingly untenable for the sandbox code to chase the incoming tor-launcher changes, in particular it is unlikely that I will be willing or able to replicate the UI/UX improvements or the circumvention auto-discovery feature. It would be a colossal waste of resources to re-implement something like "auto discover bridges". So, if people have a better plan than "the only guaranteed maintenance it gets is that it will get fixes when it breaks on Yawning's laptop, or when people submit detailed bug reports that Yawning can fix in spare time", I'm open to hearing them now. Regards, -- Yawning Angel

5 14

Re: [tbb-dev] So, about the Linux sandbox in the long term?
by Nathan Freitas 30 May '17

30 May '17

On Tue, May 30, 2017, at 02:51 PM, Hans-Christoph Steiner wrote: > > Tom Ritter: > > On 30 May 2017 at 13:22, Hans-Christoph Steiner > > <hans(a)guardianproject.info> wrote: > >> As for Android apps updating their own code, it is possible, and it is > >> occasionally done. > > > > Can it be prevented? > > Android now sets the /data and /sdcard partitions so that code cannot be > executed from them. Those are the only places that apps have permission > to write. So apps cannot download and store code. The only option is > to download code and keep it in RAM. However, we could download a new tor binary, or PT's on demand, at least in the current configuration, since those are just command line executable we unpack and store in data. You can execute binaries from within /data - you just need to chmod them first. It is only /sdcard where that is not allowed. I think you can also download shared libraries anywhere, and just load them via System.load() with an arbitrary path. I do agree, there is benefit from keeping the tor process in an isolated sandbox from the browser process. This has been the discussion we have been having around a core "Tor Network Services" APK, that would be essentially an invisible dependency much like Google Play Services. +n

2 1

Re: [tbb-dev] Where is Orfox being developed?
by Nathan Freitas 25 May '17

25 May '17

On Tue, May 23, 2017, at 06:29 AM, e3b(a)riseup.net wrote: > all the sites linked to on https://guardianproject.info/apps/orfox/ are > inactive, except for the repository on > https://gitweb.torproject.org/tor-browser.git/ , where Georg Koppen > seems to be the only active contributor. We have a #tor-mobile channel on OFTC that is becoming more active. Otherwise, this is the main repo for builds: https://github.com/guardianproject/Orfox and this is the repo where we track the main tor-browser code with patches for Android: https://github.com/guardianproject/tor-browser/tree/0d08726e5067b9d608f6fa2… Since Orfox is mostly a rebase and tweak on top of Georg and other's work on the main tor-browser project, it can sometimes seem like it isn't very active. Also, we've been spending a lot of energy working on iOS efforts, since the state of a tor-based browser there has not been very good. More on that soon. +n

1 0

Where is Orfox being developed?
by e3b＠riseup.net 23 May '17

23 May '17

Hi, all the sites linked to on https://guardianproject.info/apps/orfox/ are inactive, except for the repository on https://gitweb.torproject.org/tor-browser.git/ , where Georg Koppen seems to be the only active contributor. How can I get up to date on the development? Thanks! -- e3b

1 0

Next Tor Browser meeting: Tue, May 30 1800 UTC in #tor-dev
by Georg Koppen 22 May '17

22 May '17

Hi all, Next Monday is Memorial Day in the U.S. and we'll therefore move the meeting by one day. New meeting time for next week is: Tuesday, May 30, 1800 UTC. As usual we'll gather in #tor-dev for status updates and items that need further discussion. Feel free to drop by! Georg

1 0

Tag: sandboxed-tor-browser-0.0.7
by Yawning Angel 22 May '17

22 May '17

Hello, I went and tagged this, because it's a good idea, and despite the changes being minor there's no reason to sit on them. Changes in version 0.0.7 - 2017-05-22: * Bug 21977: Fetch install/update metadata files from a different location. * Bug 22038: Stub out `pa_start_child_for_read`. This is the first release that will use `update_3`, so until prior releases are dead, `update_2` will need to be kept, well up to date. The PulseAudio related change is more for peace of mind than anything else. I don't think it's particularly harmful or exploitable, but removing it doesn't hurt, so I did. See the bug for more details. Regards, -- Yawning Angel ps: As far as I am aware (though I stopped using the alpha series as my daily driver as of the ESR52 transition), 7.0 works as well in the sandbox as elsewhere, so there shouldn't need to be any more changes. Let me know if this is not the case.

1 0

SELFRANDO_write_layout_file enabled intentionally?
by Rusty Bird 19 May '17

19 May '17

Hi, start-tor-browser sets the SELFRANDO_write_layout_file environment variable to an empty string, which *enables* [1] the creation of the 7 MB /tmp/<PID>.mlf layout file. This adds 2 seconds of startup time on my system. Would it make sense to *disable* it for alpha/stable builds? If so, the export line in start-tor-browser should be removed. (People who really want the layout file for debugging could still enable it by running "SELFRANDO_write_layout_file= ./start-tor-browser".) Rusty 1. https://github.com/immunant/selfrando/blob/73f33ecc8031bdf9c2ba8d95191b23f7…

6 6