tbb-dev June 2017

tbb-dev@lists.torproject.org

6 participants
7 discussions

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

Next Tor Browser meeting: Wed, Jul 5 1800 UTC
by Georg Koppen 22 Jun '17

22 Jun '17

Hi, The next Tor Browser meeting will be on Wednesday, July 5 at 1800 UTC. Not sure if #tor-dev will be occupied with an other meeting then. If so we'll move to #tor-project. See you then, Georg

1 0

Tag: sandboxed-tor-browser-0.0.8
by Yawning Angel 20 Jun '17

20 Jun '17

Hello, I went and tagged this, because I don't want to sit on the relatively large #22648 change. Changes in version 0.0.8 - 2017-06-19: * Bug 20776: Remove the X11 `MIT-SHM` workaround from the stub. * Bug 22470: Resync the bridges. * Bug 22607: Make it clear that basically 0 active development is happening. * Bug 22648: Prevent the "easy" to fix X11 related sandbox escapes. * Bug 22650: Make it clear that Pulse Audio is potentially dangerous to enable. Thanks to Jann Horn of Google Project Zero for providing the report that motivated #22648 and #22650. Since there was some confusion, for clarity and the record, the sandbox does not, and never has, considered most X11 or PulseAudio related issues to be part of it's current threat model, with the exception of what (minimal if any) mitigations happen to be in place. Both protocols likely still will allow sophisticated adversaries to do evil. The documentation on the trac wiki page has received updates to clarify this situation. The recommendation for people that are concerned about such things always has been, and still is "Use a separate X11 isolation option"/"Wait for Wayland to magically fix everything", and "disable PulseAudio" support. Note that this does not mean that I won't accept bug reports or suggestions to improve the X11/PulseAudio situations, but as the other change notes "Basically 0 active development is happening". Tested on Arch Linux and Fedora 25. If it happens to break on something else, patches accepted. Regards, -- Yawning Angel

1 1

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

Tor Browser 7.0 updater tests
by Mark Smith 06 Jun '17

06 Jun '17

Over the past 1.5 days, Kathy and I used installers and MAR files from https://people.torproject.org/~gk/builds/7.0 to perform various updater tests on the following platforms: * 64-bit Ubuntu 14.04.5 LTS (desktop PC). * 32-bit Ubuntu 16.04.2 LTS (VM) * OSX 10.12.5 (Retina MacBook Pro) * 32-bit Windows 7 Pro (VM). * 64-bit Windows 10.0.15063 (Lenovo touch screen laptop) We hosted XML update manifests (not the ones generated by the build process though) and MAR files on our own HTTP server. We did not find any problems during any of our tests. Here is a description of the two kinds of tests we did: (a) Upgrades from Tor Browser 6.5.2 to 7.0. This was mainly a test of the 6.5.2 updater and the 7.0 MAR files. We tested various combinations of: * staged updates (Linux, OSX) * unstaged updates (all platforms) * incremental updates * full updates * en-US locale * es-ES locale * with various built-in bridges enabled: obfs3, obfs4, meek-azure. While we did not exhaustively test every combination on each platform, we feel good about the amount of testing that we did. (b) "Upgrades" from 7.0 to 7.0. This was done to exercise the 7.0 updater and ensure that it works in at least the full update case. To do this kind of testing we trick the update service into thinking there is a 7.0.1 update available (via tweaks to the XML update manifest on our HTTP server) and use a complete 7.0 MAR file for the "update." We tested scenarios similar to the ones I mentioned under (a) above, except partial updates are not an option in this case. -- Mark Smith Pearl Crescent http://pearlcrescent.com/

1 0

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

Fwd: Crash Reporter for Tor Browser - GSoC 2017 Intro
by Tom Ritter 02 Jun '17

02 Jun '17

Hey all, Nur-Magomed will be in irc (probably #tor-dev unless we need to move because it conflicts with another meeting) twice a week for status checkins and general dedicated "help with bugs and errors" time. If you're able to pop into irc or keep an eye on it during those times, that would be fantastic, since you might know an aswer I don't. - Wednesday 3PM UTC (That's 11 AM EDT) - Friday same time -tom ---------- Forwarded message ---------- From: Nur-Magomed <nmagoru(a)gmail.com> Date: 12 May 2017 at 13:25 Subject: Crash Reporter for Tor Browser - GSoC 2017 Intro To: tor-project(a)lists.torproject.org Cc: Tom Ritter <tom(a)ritter.vg>, Georg Koppen <gk(a)torproject.org>, Damian Johnson <atagar(a)torproject.org> * Didn't change the title in previous letter, sorry :/ Hi everyone! My name is Nur-Magomed, I’m 4th year student from North-Caucasus Federal University, Russia. This summer, I will be working on Crash Reporter for Tor Browser as a part of GSoC 2017. My mentors are: Tom Ritter - Primary Mentor, Georg (gk) - Backup Mentor. At the beginning I would like to thank all Tor dev community and my mentors that helped me and accepted my proposal, I’m glad to be a part of Tor dev community! About project Crash Reporter will be helping developers to improve Tor Browser, find bugs and crash reasons easier, that would make Tor Browser more stable and user-friendly. Mozilla Firefox has the crash reporter based on Google BreakPad with server side - Mozilla Socorro. My summer work is focused at adapting Firefox Crash Reporter for Tor Browser (Linux version). And also adapting Socorro for changed Crash Reporter and run it as “.onion” service. Full project proposal can be found at blog [1] or in PDF file [2]. Project timeline GSoC coding period starts on May 30 and ends on August 21 comprising a total of 12 weeks: week 1 - 5 : Crash Reporter client side | +--- week 1+2 : Build Tor Browser with Crash reporter. Improving crash data minidumps generator (don’t save privacy data in reports) | +--- week 3 : Redesign report’s client UI form, making functionality to delete data after sent, removing not necessary UI functions | +--- week 4 : Adapting report’s sender for Tor network (sending through Tor network) | +--- week 5 : Testing and review code week 6 - 11 : Crash Reporter server side based on Socorro | +---week 6+7 : working on Collector, adapting it according to changed minidumps | +---week 8+9 : updating DB structure, adapting Processor (for DB and for Collector’s reports) | +---week 9+10 : Working on statistic site - updating design templates, ORM classes for DB, and etc. | +---week 11 : Testing and review code. Setting up service on Tor network. week 12: Final testing, documentation Before coding will start there are some tasks to do (I'm starting work): > be sure which ones of fields or of their combinations could be privacy-sensitive > find the best way that explains to user what happened and what he can do after crash (in UI design) > try build Tor Browser with Crash Reporter from Firefox [for Linux] I will send bi-weekly status reports to this list, and also public it on my blog [1]. Please don’t hesitate to contact me if you have any suggestions. E-Mail: nmagoru [at] gmail.com IRC (OFTC): nmago Time Zone: UTC+03:00 Kind regards, Nur-Magomed Links: [1] https://torcrashreporter.wordpress.com/2017/04/03/google-summer-of-code-pro… [2] https://torcrashreporter.files.wordpress.com/2017/05/final_proposal.pdf

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev June 2017