September 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

Roadmaps and funding moving forward.
by isabela 06 Oct '17

06 Oct '17

Hello Tor Browser team, as we approach Montreal's meeting and teams will be creating their roadmap for the months between meetings (till winter 2018 meeting). I would like to present you a new way of relationship we are building between teams work and our funding. Tor is trying to get out of the 'deliverable' funding model, which is mostly used with the current gov grants we have. We are working to shift to funding opportunities that follows a different model, more focus on the execution of the vision of our mission than on specific deliverables. It will take some time till we have a significant part of our fund to come from this type. But we have already started to seek for these opportunities and some teams will start to shift to this model. Another thing related to this model are reports. We will still keep our work organized and have tickets associated with every item on the roadmap so we can easily tell what happened with each task. Since it is a model focus more on the execution of the vision of our mission, our accomplishments from our roadmap is what we are reporting as they are driving us towards our mission. With this said, the Tor Browser 'desktop' team is one that is starting on this model. So for the roadmap exercise in Montreal you will have some freedom when creating it. I am saying 'some' because there are tasks you can't really ignore like keeping up with ESR releases from Mozilla. I am listing here some areas of work that the team can consider tasks for the roadmap, please add more if you have any. This is just a way to start our brainstorming process for Montreal: * keep up with ESR releases * acquisition ux work - download process and get connected to the network (tor launcher) * user onboarding ux work - about:tor page * fingerprinting * selfrando * sandboxing * release infra We can use this pad to document ideas for the roadmap: https://storm.torproject.org/shared/FJWrnBf1SXemGKhOK_Wxwl57BVlj0Ynjn8lXcjF… Cheers, Isabela

2 4

Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]
by anonym 06 Oct '17

06 Oct '17

Georg Koppen: > Hi, > > Just to inform you about things we learned a couple of minutes ago: the > Firefox release is due on Thursday. It got postponed by two days mainly > to give 57 beta more publicity. > > We'll follow and release Tor Browser on Thursday as well. Got it! It makes sense for you Tor Browser folks, since the Firefox security issues fixed in ESR 52.3 are not publicly known yet (at least in theory, but the code changes have been out for a week so they can have been reverse-engineered). But what about Tails? Tails 3.2, which is ready to be published right now, would fix several publicly known security issues for our users, including some potential RCEs (Thunderbird, libsoup, ...). Of course, some of these issues have been out for weeks already, so what's two more days of delay? Still, it makes me want to remember/re-evaluate *why* we always wait on Mozilla. What are your feelings around this? What are the arguments for/against releasing early? TBH this has always seemed odd to me. I remember argument for this being about us behaving like good Free Software community members by coordinating releases. I wonder if they really care, especially given our users' position. So, let's ask them! Tor Browser folks, would you care if we released Tails 3.2 right now, so we in effect release Tor Browser 7.0.6 way before you? What do you feel about this in general? As for asking Mozilla, I'm not even sure who/where to ask. Does any one have a clue? Cheers!

4 8

sandboxed-tor-browser and TBB 7.5a5.
by Yawning Angel 29 Sep '17

29 Sep '17

Hello, So, 7.5a5 is newly broken with sandboxed-tor-browser, unless you're running git master (as of a few mins ago) due to https://trac.torproject.org/projects/tor/ticket/23692 Even with the uncertain future of sandboxed-tor-browser this highlights a few issues that I'm not sure how to address: * In general, it's not immediately obvious to me how I'm supposed to test for new releases of the browser requiring changes to the sandbox in time for a new sandbox build to get shipped with the new browser release. * I'm strongly tempted to drop support for the alpha channel, because I run stable builds of the browser, so that's more likely to break since it's a "install it when someone cries about it" thing for me. Suggestions welcome, in the mean time if people want to use sandboxed-tor-browser with the alpha channel, they need to build git master. Regards, -- Yawning Angel

3 6

[tag] sandboxed-tor-browser-0.0.14
by Yawning Angel 29 Sep '17

29 Sep '17

Hello, I just tagged sandboxed-tor-browser 0.0.14. Changes in version 0.0.14 - 2017-09-29: * Bug 8706: Fully disable the .recently-used.xbel. * Bug 22814: Revert the upstream fix by default. * Bug 23692: Add PR_SET_NO_NEW_PRIVS as an allowed prctl() operation. There aren't many changes, but the fix to #23692 is required for 7.5a5 to function correctly. The stable channel is unaffected. It appears that the change for the behavior reverted was "fixed" as bug #10089 (instead of #22814). If people want the "new" behavior that totally screws with workflow and habits that I established in the 1990s, they can flip the pref by hand. Regards, -- Yawning Angel

1 0

[mobile browser developer candidate] Bug 16678 - Enhance KeyboardEvent fingerprinting resistence
by Matthew Finkel 26 Sep '17

26 Sep '17

Hi All, I pushed a final branch for this ticket [0]. I'll update the ticket, as well. As mentioned on the ticket, this enhancement was complicated by the fact that unicode codepoints are accessible by keys directly on the keyboard, as well as using dead keys + another character. The former, using a dead key combination, dispatches multiple keydown events, while the latter only dispatches a single keydown event. As a mitigation, we can suppress the keydown event generated by the dead key, exactly the same way the Alt/AltGr/Shift keys are suppressed [1]. The result of this is simply only emitting a keypress of the raw keyboard character, and to a webpage it appears like the dead key wasn't pressed. I believe I know how we can implement this correctly, such that "dead key + character" appears identical to a keyboard character. Many thanks to Arthur for his valuable feedback, [2] includes some fixups and improvements. Thank you, Matt [-1] https://trac.torproject.org/projects/tor/ticket/16678 [0] https://github.com/sysrqb/tor-browser/tree/bug16678_2 [1] https://github.com/sysrqb/tor-browser/commit/29d8c9ffec2340e64ad26a0dbc4831… [2] https://github.com/sysrqb/tor-browser/commit/962194b1151768ddc6d3beb30132d8…

1 0

build failure with runc-1.0.0
by Matthew Finkel 19 Sep '17

19 Sep '17

Hi All, I've tried building TB via tor-browser-build using runc-1.0.0-rc2 and it is currently failing. Has anyone recently had success with this? I created new debootstrap chroots of Xenial, Sid, Stretch, and Jessie - they all failed for one reason or another. In general I'm getting the following error, and this is caused by incorrectly parsing the Capabilities object in the runc-config.json file (expecting an array of capabilities, but the file containing the Capabilities object with array members is malformed). I understand the reasoning behind the error, from bug 23039, but I'm not sure why runc is expecting the old format. $ make release git submodule update --init ./rbm/rbm build release --target release --target torbrowser-all Building project tor-browser - tor-browser-7.5a4-linux-x86_64-7de4de Building project container-image - container-image_wheezy-amd64-df3a332e7b34.tar.gz Building project debootstrap-image - container-image_wheezy-amd64.tar.gz Using file /home/sysrqb/tor-browser-build/out/debootstrap-image/container-image_ubuntu-base-17.04-base-amd64.tar.gz Error: Error starting remote: json: cannot unmarshal object into Go struct field Process.capabilities of type []string Makefile:6: recipe for target 'release' failed make: *** [release] Error 1 $ sudo runc --version runc version spec: 1.0.0-rc2-dev $ apt-cache show runc Package: runc Version: 1.0.0~rc2+git20170201.133.9df8b30-3 I suspect this is some incompatibility in my system and it's partially caused by running this in a chroot, but I'm not exactly certain. I successfully built a torbrowser release using a fresh vm running Debian Stretch and checking out commit HEAD~ in tor-browser-build, master's HEAD failed. It seems the template for choosing between `runc start` and `runc run` chose the wrong subcommand: $ make release git submodule update --init ./rbm/rbm build release --target release --target torbrowser-all Building project tor-browser - tor-browser-7.5a4-linux-x86_64-7de4de Building project container-image - container-image_wheezy-amd64-df3a332e7b34.tar.gz Building project debootstrap-image - container-image_wheezy-amd64.tar.gz Using file /home/sysrqb/tor-browser-build/out/debootstrap-image/container-image_ubuntu-base-17.04-base-amd64.tar.gz Error: Error starting remote: No help topic for 'run' Makefile:6: recipe for target 'release' failed make: *** [release] Error 1 $ sudo runc --version runc version 0.1.1 spec: 1.0.0-rc1 $ apt-cache show runc Package: runc Source: runc (0.1.1+dfsg1-2) Version: 0.1.1+dfsg1-2+b2 [...] Thanks, Matt

2 1

Fix for bug 23104
by igt0 /dev/nul 16 Sep '17

16 Sep '17

Howdy, I submitted a patch for the bug 23104[1]. The solution proposed in the patch uses a default factor to be multiplied as ascender and descender values. This way all operating systems will have the same line height. [1] https://trac.torproject.org/projects/tor/ticket/23104 Cheers, Igt0

1 0

[tag] sandboxed-tor-browser 0.0.13
by Yawning Angel 13 Sep '17

13 Sep '17

Hello, (Resending because I sent it to the -bounces address instead, sorry if this results in duplicates.) I tagged sandboxed-tor-browser 0.0.13. Changes in version 0.0.13 - 2017-09-13: * Bug 13170: Disable the rest of the Firefox experiments botnet prefs. * Bug 23449: Allow `epool_pwait` in the tor seccomp rules. * Use lockPref for the IDN override done as part of #22984. * Unset the addon autoupdater URL prefs. * Disable the "Open with" dialog, which will never work. * Use the GCC constructor attribute for stub initialization. The important change is the `epoll_pwait` change which solves tor failing to launch on certain systems with glibc compiled against newer kernels due to a seccomp violation triggered by libevent. Regards, -- Yawning Angel

1 0

Fwd: Intent to ship: Use Songti TC and Songti SC as default font for zh locales
by Tim Huang 11 Sep '17

11 Sep '17

Default font changing for Chinese fonts that we need to consider. ---------- Forwarded message ---------- From: Tim Guan-tin Chien <timdream(a)mozilla.com> Date: Thu, Sep 7, 2017 at 4:11 PM Subject: Intent to ship: Use Songti TC and Songti SC as default font for zh locales To: dev-platform <dev-platform(a)lists.mozilla.org>, Makoto Kato < mkato(a)mozilla.com> Songti TC/SC are new Chinese serif fonts since OS X Mavericks. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1350766 Other vendors: Chrome and Safari have already use it in their release version. Extimated target release: The above bug will ship it to early Beta 57 population and Nightly 57. If it goes well we should ship this in Release 58. Tim _______________________________________________ dev-platform mailing list dev-platform(a)lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Tim Huang Mozilla Taiwan email:tihuang@mozilla.com phone:+886-2-8786-1100#402 <+886%202%208786%201100>

2 1