- tbb-dev - lists.torproject.org

Tor Browser meetings are moving to #tor-meeting from now on
by Georg Koppen 02 Oct '17

02 Oct '17

Hi all! Just a gentle reminder that we are moving our meetings to #tor-meeting from now on. Time and date remain the same (18:00UTC on Monday). For background see: https://lists.torproject.org/pipermail/tor-project/2017-September/001459.ht… Georg

1 0

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

Meeting today
by Georg Koppen 04 Sep '17

04 Sep '17

Hi! I just realized (again :/) that I missed a national holiday in the US when doing meeting planning. Thus, I am inclined to meet up today for a status update. If folks are not available today due to Labor Day in the US that's fine. Sorry, Georg

1 0

Pearl Crescent weekly status update
by Mark Smith 28 Aug '17

28 Aug '17

I should have mentioned last week that Kathy and I will be out of the office at various times this week, including all day tomorrow (Monday), all day Thursday, and parts of other days. I am sorry we will miss the weekly meeting again, but here is our status report: Last week, Kathy and I worked more on implementation of the configuration portion of the new Tor Launcher design (#23261). We made a "work in progress" add-on available so people can experiment with the new UI. Then we worked on integrating a simple progress bar into the Tor Launcher setup wizard (#23262). Doing this will get us closer to the full UX that Linda designed, although we will need to implement a more informative progress bar later. We also purchased airline tickets for the Montreal Tor meeting, so our travel plans are all set now. Kathy and I will arrive Wednesday morning and we will fly back to Michigan on Saturday afternoon. This week, we will continue to work on the new Tor Launcher UI, especially the integrated progress bar. Also, since we did not get to it last week, we plan to create follow up patches for #22618 ("Downloading pdf file via file:/// is stalling if the external helper dialog is enabled"). -- Mark Smith Pearl Crescent http://pearlcrescent.com/

1 0