tbb-dev

tbb-dev@lists.torproject.org

447 discussions

Symantec CA
by Jeff Burdges 30 May '16

30 May '16

Apologies if this is kinda a dumb question. Symantec has some issues as a CA : http://www.tomshardware.com/news/google-removes-symantec-root-certificate,3… https://blog.filippo.io/untrusting-an-intermediate-ca-on-os-x/ I cannot find any certificates by them in either Iceweasel or TBB. Yet, neither can I find any negative news articles on their status with Mozilla. Were they excluded in the past for seeming untrustworthy? Or are they valid but not showing up for some other reason? Thanks, Jeff

2 1

Fwd: Q1 Summary from Chrome Security
by Tom Ritter 06 May '16

06 May '16

This quarterly newsletter that Chrome puts out is pretty cool. There's some new Windows 10 security features I hope Mozilla is investigating! ---------- Forwarded message ---------- From: Parisa Tabriz <parisa(a)chromium.org> Date: 3 May 2016 at 19:27 Subject: Q1 Summary from Chrome Security To: Chromium-dev <chromium-dev(a)chromium.org>, security-dev <security-dev(a)chromium.org> Cc: "security(a)chromium.org" <security(a)chromium.org>, "security-notify(a)chromium.org" <security-notify(a)chromium.org> Greetings web fans, For those that don’t know us already, we do stuff to help make Chrome the most secure platform to browse the Internet. Here’s a recap of some work from last quarter: The Bugs-- effort aims to find (and exterminate) security bugs. On the fuzzing front, we’ve continued to improve the integration between libFuzzer and ClusterFuzz, which allows coverage-guided testing on a per-function basis. With the help of many developers across several teams, we’ve expanded our collection of fuzzing targets in Chromium (that use libFuzzer) to 70! Not all bugs can be found by fuzzing, so we invest effort in targeted code audits too. We wrote a guest post on the Project Zero blog describing one of the more interesting vulnerabilities we discovered. Since we find a lot of bugs, we also want to make them easier to manage. We’ve updated our Sheriffbot tool to simplify the addition of new rules and expanded it to help manage functional bugs in addition just security issues. We’ve also automated assigning security severity recommendations. Finally, we continue to run our vulnerability reward program to recognize bugs discovered from researchers outside of the team. As of M50, we’ve paid out over $2.5 million since the start of the reward program, including over $500,000 in 2015. Our median payment amount for 2015 was $3,000 (up from $2,000 for 2014), and we want to see that increase again this year! Bugs still happen, so our Guts effort builds in multiple layers of defense. On Android, our seccomp-bpf experiment has been running on the Dev channel and will advance to the Stable and Beta channels with M50. Chrome on Windows is evolving rapidly in step with the operating system. We shipped four new layers of defense in depth to take advantage of the latest capabilities in Windows 10, some of which patch vulnerabilities found by our own research and feedback! There was great media attention when these changes landed, from Ars Technica to a Risky Business podcast, which said: “There have been some engineering changes to Chrome on Windows 10 which look pretty good. … It’s definitely the go-to browser, when it comes to not getting owned on the internet. And it’s a great example of Google pushing the state of the art in operating systems.” For our Site Isolation effort, we have expanded our on-going launch trial of --isolate-extensions to include 50% of both Dev Channel and Canary Channel users! This mode uses out-of-process iframes (OOPIFs) to keep dangerous web content out of extension processes. (See here for how to try it.) We've fixed many launch blocking bugs, and improved support for navigation, input events, hit testing, and security features like CSP and mixed content. We improved our test coverage and made progress on updating features like fullscreen, zoom, and find-in-page to work with OOPIFs. We're also excited to see progress on other potential uses of OOPIFs, including the <webview> tag and an experimental "top document isolation" mode. We spend time building security features that people see. In response to user feedback, we’ve replaced the old full screen prompt with a new, lighter weight ephemeral message in M50 across Windows and Linux. We launched a few bug fixes and updates to the Security panel, which we continue to iterate on and support in an effort to drive forward HTTPS adoption. We also continued our work on removing powerful features on insecure origins (e.g. geolocation). We’re working on preventing abuse of powerful features on the web. We continue to support great “permissions request” UX, and have started reaching out to top websites to directly help them improve how they request permissions for powerful APIs. To give top-level websites more control over how iframes use permissions, we started external discussions about a new Permission Delegation API. We also extended our vulnerability rewards program to support Safe Browsing reports, in a first program of its kind. Beyond the browser, our web platform efforts foster cross-vendor cooperation on developer-facing security features. We now have an implementation of Suborigins behind a flag, and have been experimenting with Google developers on usage. We polished up the Referrer Policy spec, refined its integration with ServiceWorker and Fetch, and shipped the `referrerpolicy` attribute from that document. We're excited about the potential of new CSP expressions like 'unsafe-dynamic', which will ship in Chrome 52 (and is experimentally deployed on our shiny new bug tracker). In that same release, we finally shipped SameSite cookies, which we hope will help prevent CSRF. Lastly, we're working to pay down some technical debt by refactoring our Mixed Content implementation and X-Frame-Options to work in an OOPIF world. We see migration to HTTPS as foundational to any security whatsoever (and we're not the only ones), so we're actively working to drive #MOARTLS across Google and the Internet at large. We worked with a number of teams across Google to help publish an HTTPS Report Card, which aims to hold Google and other top sites accountable, as well as encourage others to encrypt the web. In addition to #MOARTLS, we want to ensure more secure TLS. We mentioned we were working on it last time, but RC4 support is dead! The insecure TLS version fallback is also gone. With help from the libFuzzer folks, we got much better fuzzing coverage on BoringSSL, which resulted in CVE-2016-0705. We ended up adding a "fuzzer mode" to the SSL stack to help the fuzzer get past cryptographic invariants in the handshake, which smoked out some minor (memory leak) bugs. Last, but not least, we rewrote a large chunk of BoringSSL's ASN.1 parsing with a simpler and more standards-compliant stack. Until next time... Happy Hacking, Parisa, on behalf of Chrome Security P.S. For more thrilling security updates and feisty rants, subscribe to security-dev(a)chromium.org. You can find older updates at https://dev.chromium.org/Home/chromium-security/quarterly-updates. -- You received this message because you are subscribed to the Google Groups "Security-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe(a)chromium.org.

1 1

Test updates for ESR45
by Nicolas Vigier 02 May '16

02 May '16

Hello, Following, the ESR45 changes, I made (or will make) the following changes to the tests: - updated the esr version in the useragent string, in settings, fp_useragent, fp_navigator tests - removed the dom.workers.sharedWorkers.enabled pref from the settings test, as this pref has been removed from firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1207635 - in fp_navigator, changed navigator['mozTCPSocket'] expected value from null to undefined - in dom-objects-enumeration, we have the following new objects in the global namespace that I'm going to add the the whitelist: Directory Headers SourceBufferList SourceBuffer VideoPlaybackQuality ScreenOrientation CacheStorage FontFaceSet CanvasCaptureMediaStream TextTrackCue Request ImageBitmap FontFaceSetLoadEvent Cache Response fetch createImageBitmap caches onstorage Nicolas

1 0

Trouble building Tor Browser on Debian stretch
by David Fifield 27 Apr '16

27 Apr '16

I'm trying to build Tor Browser (tbb-6.0a4-build1) on Debian stretch, and running into problems. I tried some workarounds but it seems like I must be trying to do something unsupported. I'm not trying to reproduce a package; just test a patch. Can anyone shed some light? One of the problems seems actionable so I made a ticket: https://bugs.torproject.org/18786. I had to install the vmbuilder script manually, so I did what check-prerequisites.sh told me to do: torsocks wget -U "" https://bugs.launchpad.net/ubuntu/+archive/primary/+files/vm-builder_0.12.4… echo "76cbf8c52c391160b2641e7120dbade5afded713afaa6032f733a261f13e6a8e vm-builder_0.12.4+bzr494.orig.tar.gz" | sha256sum -c tar -zxvf vm-builder_0.12.4+bzr494.orig.tar.gz cd vm-builder-0.12.4+bzr494 sudo python setup.py install I ran into two problems that I tried to fix by patching vmbuilder. The first is that the call to "update-grub -y" would fail. I traced the problem to a lack of /dev inside the chroot; update-grub runs grub-probe --device-map=/boot/grub/device.map -t device / which fails with grub-probe: error: cannot find a device for / (is /dev mounted?). For this, I copy-pasted some code to bind-mount /dev before the call and unmount it after. Then I had a problem during the dist-upgrade for the ubuntu precise VMs. The "initscripts" package was failing to upgrade from 2.88dsf-13.10ubuntu11 to 2.88dsf-13.10ubuntu11.1: Setting up initscripts (2.88dsf-13.10ubuntu11.1) ... Processing triggers for libc-bin ... ldconfig deferred processing now taking place Extracting templates from packages: 100% Current default time zone: 'Etc/UTC' Local time is now: Mon Apr 11 01:35:59 UTC 2016. Universal Time is now: Mon Apr 11 01:35:59 UTC 2016. Run 'dpkg-reconfigure tzdata' if you wish to change it. invoke-rc.d: policy-rc.d denied execution of stop. mkdir: cannot create directory `/run/shm': File exists The specific error is that mkdir is trying to create a directory over an existing symlink. It's related to some confusion between /dev/shm and /run/shm: https://bugs.launchpad.net/bugs/974584. Here I spliced in a hack to remove the symlink and create the directory before upgrading initscripts. Finally I hit a compiler error during the build of i386 linux tor-browser. It's complaining about -Wformat-security: c++ -o MetaData.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include /home/debian/build/tor-browser/config/gcc_hidden.h -DANDROID_SMP=0 -DLOG_NDEBUG=1 -D_GLIBCXX_OS_DEFINES -DHAVE_SYS_UIO_H -DFAKE_LOG_DEVICE -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DMOZ_GLUE_IN_PROGRAM -DAB_CD=en-US -DNO_NSPR_10_SUPPORT -I/home/debian/build/tor-browser/media/libstagefright -I. -I/home/debian/build/tor-browser/media/libstagefright/binding/include -I/home/debian/build/tor-browser/media/libstagefright/frameworks/av/include -I/home/debian/build/tor-browser/media/libstagefright/frameworks/av/include/media/stagefright/foundation -I/home/debian/build/tor-browser/media/libstagefright/frameworks/av/media/libstagefright/ -I/home/debian/build/tor-browser/media/libstagefright/stubs/empty -I/home/debian/build/tor-browser/media/libstagefright/stubs/include -I/home/debian/build/tor-browser/media/libstagefright/stubs/include/media/stagefright/foundation -I/home/debian/build/tor-browser/media/libstagefright/system/core/include -I../../dist/include -I/home/debian/build/tor-browser/obj-i686-pc-linux-gnu/dist/include/nspr -I/home/debian/build/tor-browser/obj-i686-pc-linux-gnu/dist/include/nss -fPIC -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MP -MF .deps/MetaData.o.pp -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -frandom-seed=tor -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -freorder-blocks -Os -fomit-frame-pointer -Wno-format -Wno-multichar -Wno-sign-compare -Wno-unused /home/debian/build/tor-browser/media/libstagefright/frameworks/av/media/libstagefright/MetaData.cpp cc1plus: error: -Wformat-security ignored without -Wformat [-Werror=format-security] I didn't find a way to deal with this one. I noticed that a recent commit refers to -Wformat-security in a comment, but it seems to be about GCC, not Firefox: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/d…

2 2

Nightly hardened
by Linus Nordberg 25 Apr '16

25 Apr '16

Hi, https://people.torproject.org/~linus/builds/ now contains hardened builds as well. They're built when the ordinary nigthlies are built, namely every morning (CET/CEST) when there's been commits to the tor-browser-bundle repository or at least every third day regardless of new commits. I'd like to take the opportunity to hear what the opinion of the list is regarding moving the start of the build from todays 06:10 to 04:30. The idea is that both builds would be done when an ordinary working day starts in CET/CEST. This would increase the risk that late commits from US people won't make it, 04:30 CEST being 02:30 UTC.

2 2

marionette tests - how?
by gunes acar 22 Apr '16

22 Apr '16

Hi Nicolas, I saw you added Marionette tests to TBB test suite. I wonder how did you get Marionette to work with ESR38. I get "Missing marionetteProtocol field in handshake" error when I initialize webdriver with marionette capability using either TB 5.5.4 or stock ESR38 as firefox_binary [1]. The same code works with Firefox 45. I see this firefox-ui-tests submodule checked out to a commit in Oct. 2015. Is this the secret sauce? And I can't see "wires" mentioned in the test suite. Is it installed on the test machines already, or is there a way to do without wires? Thanks a lot! Gunes [1]: https://gist.github.com/gunesacar/81ce3d54d3ea0e797102f8c302c6ab82#file-mar…

1 1

Re: [tbb-dev] Trouble building Tor Browser on Debian stretch
by Joseph Bisch 22 Apr '16

22 Apr '16

I usually run Gitian directly on whatever host OS I use, so I don't have experience with running it in a chroot. When I was trying to reproduce the issues using a Stretch chroot and trying to create a Precise VM in it, I actually couldn't get far enough to reach the issues you were experiencing. What command are you using to enter the Stretch chroot (like chroot or systemd-nspawn)? I would bring the patches up to upstream[0] and see what they think about them. [0] - https://launchpad.net/vmbuilder Cheers, Joseph

2 1

Chris Palmer's Chrome Settings
by Jeff Burdges 15 Apr '16

15 Apr '16

I suspect anyone here noticed this previously, but searching for tbb-dev + [related] yielded nothing, so maybe it's worth mentioning here. https://noncombatant.org/2014/03/11/privacy-and-security-settings-in-chrome/ At minimum, if you've anyone bound and determined to use Chrome over Tor, then you can point them towards this. Best, Jeff

1 0

Tor Browser 5.0.8 delayed until 2016-04-26?
by anonym 12 Apr '16

12 Apr '16

Hi, As you can see on https://wiki.mozilla.org/RapidRelease/Calendar the release date for Firefox 38.8 (and friends) has been delayed one week, from the 19th to the 26th. I suppose this also means that the next Tor Browser (5.0.8, I guess) will be delayed until then too, right? Cheers!

2 2

Missing meeting
by Arthur D. Edelstein 04 Apr '16

04 Apr '16

Hi everyone, Due to travel it looks like I will probably miss the meeting today. If so, I will send my status report this evening. Arthur

1 0

← Newer
1
...
29
30
31
32
33
34
35
...
45
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev