tor-commits November 2014

tor-commits@lists.torproject.org

24 participants
954 discussions

[tor-browser/tor-browser-31.2.0esr-4.5-1] It seems like we need to add one more path traversal for ESR31
by mikeperry＠torproject.org 03 Nov '14

03 Nov '14

commit 892f8b664e82abe2afb9b488f5e095c7d4006629 Author: Tom Ritter <tom(a)ritter.vg> Date: Mon Oct 27 11:31:20 2014 -0500 It seems like we need to add one more path traversal for ESR31 --- toolkit/library/dependentlibs.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/toolkit/library/dependentlibs.py b/toolkit/library/dependentlibs.py index 4331cfa..4889a1e 100644 --- a/toolkit/library/dependentlibs.py +++ b/toolkit/library/dependentlibs.py @@ -71,7 +71,7 @@ def dependentlibs_readelf(lib): def dependentlibs_otool(lib): '''Returns the list of dependencies declared in the given MACH-O dylib''' - proc = subprocess.Popen(["../../../../x-tools/x86_64-apple-darwin10/bin/" + TOOLCHAIN_PREFIX + 'otool', '-l', lib], stdout = subprocess.PIPE) + proc = subprocess.Popen(["../../../../../x-tools/x86_64-apple-darwin10/bin/" + TOOLCHAIN_PREFIX + 'otool', '-l', lib], stdout = subprocess.PIPE) deps= [] cmd = None for line in proc.stdout:

1 0

[tor-browser/tor-browser-31.2.0esr-4.5-1] Changes needed to build Mac in 64bit
by mikeperry＠torproject.org 03 Nov '14

03 Nov '14

commit b8b6d86a5b6407b9e0f42bfe1de188e5be49b47d Author: Tom Ritter <tom(a)ritter.vg> Date: Tue Sep 16 08:10:50 2014 -0500 Changes needed to build Mac in 64bit --- .mozconfig-mac | 4 ++-- toolkit/library/dependentlibs.py | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.mozconfig-mac b/.mozconfig-mac index 4abcc7c..2c06c34 100644 --- a/.mozconfig-mac +++ b/.mozconfig-mac @@ -2,7 +2,7 @@ export CROSS_COMPILE=1 SYSROOTDIR=/usr/lib/apple/SDKs/MacOSX10.6.sdk ROOTDIR="$HOME/build/x-tools/x86_64-apple-darwin10/bin" -FLAGS="-arch i386 -isysroot $SYSROOTDIR" +FLAGS="-arch x86_64 -isysroot $SYSROOTDIR" # Ideally we use the patch provided in # https://bugzilla.mozilla.org/show_bug.cgi?id=933071 to get rid of our path @@ -26,7 +26,7 @@ mk_add_options MOZ_APP_DISPLAYNAME="Tor Browser" mk_add_options MOZILLA_OFFICIAL=1 mk_add_options BUILD_OFFICIAL=1 -ac_add_options --target=i386-apple-darwin10 +ac_add_options --target=x86_64-apple-darwin10 ac_add_options --enable-application=browser ac_add_options --enable-strip ac_add_options --enable-official-branding diff --git a/toolkit/library/dependentlibs.py b/toolkit/library/dependentlibs.py index 43433a1b..4331cfa 100644 --- a/toolkit/library/dependentlibs.py +++ b/toolkit/library/dependentlibs.py @@ -71,7 +71,7 @@ def dependentlibs_readelf(lib): def dependentlibs_otool(lib): '''Returns the list of dependencies declared in the given MACH-O dylib''' - proc = subprocess.Popen(['otool', '-l', lib], stdout = subprocess.PIPE) + proc = subprocess.Popen(["../../../../x-tools/x86_64-apple-darwin10/bin/" + TOOLCHAIN_PREFIX + 'otool', '-l', lib], stdout = subprocess.PIPE) deps= [] cmd = None for line in proc.stdout:

1 0

[tor-browser/tor-browser-31.2.0esr-4.5-1] Merge remote-tracking branch 'tjr/tor-browser-31.2.0esr-4.x-1-build1-64bit' into tor-browser-31.2.0esr-4.5-1
by mikeperry＠torproject.org 03 Nov '14

03 Nov '14

commit be0ac860051f1c3d61ee00a5d9140595981d3f2c Merge: e65a5a7 892f8b6 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Mon Nov 3 00:00:06 2014 -0800 Merge remote-tracking branch 'tjr/tor-browser-31.2.0esr-4.x-1-build1-64bit' into tor-browser-31.2.0esr-4.5-1 .mozconfig-mac | 4 ++-- toolkit/library/dependentlibs.py | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)

1 0

[webwml/staging] Swaps .zip with .dmg and .asc with .asc*
by sebastian＠torproject.org 02 Nov '14

02 Nov '14

commit a7d006af638268f859d60d737e6c3c49684f09f9 Author: Sherief Alaa <sheriefalaa.w(a)gmail.com> Date: Fri Oct 31 14:07:58 2014 +0200 Swaps .zip with .dmg and .asc with .asc* The tbb-team switched to a proper OS X package (.dmg) instead of .zip and Safari doesn't save .asc files as .asc files but .asc.txt --- docs/en/verifying-signatures.wml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/verifying-signatures.wml b/docs/en/verifying-signatures.wml index 52e4d37..d357e79 100644 --- a/docs/en/verifying-signatures.wml +++ b/docs/en/verifying-signatures.wml @@ -137,7 +137,7 @@ to download the ".asc" file as well. Assuming you downloaded the package and its signature to your Desktop, run:</p> - <pre>gpg --verify /Users/Alice/TorBrowser-<version-torbrowserbundleosx32>-osx-i386-en-US.zip{.asc,}</pre> + <pre>gpg --verify /Users/Alice/TorBrowser-<version-torbrowserbundleosx32>-osx-i386-en-US.dmg{.asc*,}</pre> <p>The output should say "Good signature": </p>

1 0

[webwml/staging] Bump TBB version
by sebastian＠torproject.org 02 Nov '14

02 Nov '14

commit cf7d553147c149bcbe4d9a7194f19adc0f82a485 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Fri Oct 31 20:10:06 2014 -0700 Bump TBB version --- include/versions.wmi | 10 +++++----- projects/torbrowser/RecommendedTBBVersions | 6 +++++- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/include/versions.wmi b/include/versions.wmi index ed2f305..209ceb6 100644 --- a/include/versions.wmi +++ b/include/versions.wmi @@ -23,10 +23,10 @@ <define-tag version-osx-ppc-stable whitespace=delete>0.2.3.25</define-tag> <define-tag version-osx-ppc-alpha whitespace=delete>0.2.4.17-rc</define-tag> -<define-tag version-torbrowserbundledir whitespace=delete>4.0</define-tag> +<define-tag version-torbrowserbundledir whitespace=delete>4.0.1</define-tag> <define-tag version-torbrowserbundlebetadir whitespace=delete>4.0-alpha-3</define-tag> -<define-tag version-torbrowserbundle whitespace=delete>4.0</define-tag> +<define-tag version-torbrowserbundle whitespace=delete>4.0.1</define-tag> <define-tag version-torbrowserbundlebeta whitespace=delete>4.0-alpha-3</define-tag> <define-tag version-torbrowser-tor whitespace=delete>0.2.4.19</define-tag> <define-tag version-torbrowser-tor-components whitespace=delete>libevent-2.0.21-stable, zlib-1.2.8, openssl-1.0.1e</define-tag> @@ -37,8 +37,8 @@ <define-tag version-torbrowser-vidalia whitespace=delete>0.2.21</define-tag> <define-tag version-torimbrowserbundle whitespace=delete>1.3.21</define-tag> -<define-tag version-torbrowserbundlelinux32 whitespace=delete>4.0</define-tag> -<define-tag version-torbrowserbundlelinux64 whitespace=delete>4.0</define-tag> +<define-tag version-torbrowserbundlelinux32 whitespace=delete>4.0.1</define-tag> +<define-tag version-torbrowserbundlelinux64 whitespace=delete>4.0.1</define-tag> <define-tag version-torbrowserbundlelinux32beta whitespace=delete>4.0-alpha-3</define-tag> <define-tag version-torbrowserbundlelinux64beta whitespace=delete>4.0-alpha-3</define-tag> <define-tag version-gnu-torbrowser-tor whitespace=delete>0.2.4.19</define-tag> @@ -47,7 +47,7 @@ <define-tag version-gnu-torbrowser-torbutton whitespace=delete>1.5.2</define-tag> <define-tag version-gnu-torbrowser-vidalia whitespace=delete>0.2.21</define-tag> -<define-tag version-torbrowserbundleosx32 whitespace=delete>4.0</define-tag> +<define-tag version-torbrowserbundleosx32 whitespace=delete>4.0.1</define-tag> <define-tag version-torbrowserbundleosx64 whitespace=delete>2.3.25-15</define-tag> <define-tag version-torbrowserbundleosx32beta whitespace=delete>4.0-alpha-3</define-tag> <define-tag version-osx-torbrowser-tor whitespace=delete>0.2.4.19</define-tag> diff --git a/projects/torbrowser/RecommendedTBBVersions b/projects/torbrowser/RecommendedTBBVersions index a7ee78e..d3f140a 100644 --- a/projects/torbrowser/RecommendedTBBVersions +++ b/projects/torbrowser/RecommendedTBBVersions @@ -2,5 +2,9 @@ "4.0", "4.0-Linux", "4.0-MacOS", -"4.0-Windows" +"4.0-Windows", +"4.0.1", +"4.0.1-Linux", +"4.0.1-MacOS", +"4.0.1-Windows" ]

1 0

[webwml/staging] Merge branch 'master' into staging
by sebastian＠torproject.org 02 Nov '14

02 Nov '14

commit 44d698fda36e28d74beea5fa6d1afb42a9904a79 Merge: 885532f 6b1c990 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Mon Nov 3 00:53:55 2014 +0100 Merge branch 'master' into staging docs/en/verifying-signatures.wml | 2 +- include/versions.wmi | 10 +++--- projects/torbrowser/RecommendedTBBVersions | 6 +++- projects/torbrowser/design/index.html.en | 53 +++++++++++++++++++++------- 4 files changed, 52 insertions(+), 19 deletions(-)

1 0

[webwml/staging] Describe OS type fingerprinting in TBB design doc.
by sebastian＠torproject.org 02 Nov '14

02 Nov '14

commit 6b1c990669d2086e7b83634187f4f6a2a286408b Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Fri Oct 31 22:52:49 2014 -0700 Describe OS type fingerprinting in TBB design doc. --- projects/torbrowser/design/index.html.en | 53 +++++++++++++++++++++++------- 1 file changed, 41 insertions(+), 12 deletions(-) diff --git a/projects/torbrowser/design/index.html.en b/projects/torbrowser/design/index.html.en index 65b6e98..8a32571 100644 --- a/projects/torbrowser/design/index.html.en +++ b/projects/torbrowser/design/index.html.en @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="a ffiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">October 30th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp35210336">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp37001088">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp37036336">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp37040272">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp37071376">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp35210336"></a>1. Introduction</h2></div></div></div><p> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="a ffiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">October 30th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp33097664">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp39143984">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp39178848">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp39182784">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp39214016">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp33097664"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the Tor Browser. It is current as of Tor Browser @@ -655,13 +655,13 @@ system-wide extensions (through the use of disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36779392"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp38917584"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> The User Agent MUST (at user option) prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36780752"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp38918944"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> We achieve this goal through several mechanisms. First, we set the Firefox Private Browsing preference @@ -735,7 +735,7 @@ the url bar origin for which browser state exists, possibly with a context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="idp36803456"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="idp38941648"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> This example UI is a mock-up of how isolating identifiers to the URL bar origin can simplify the privacy UI for all data - not just cookies. Once @@ -1325,6 +1325,35 @@ fingerprinting: timestamp quantization and jitter. </p><p><span class="command"><strong>Implementation Status:</strong></span> We have no implementation as of yet. + </p></li><li class="listitem">Operating System type fingerprinting + <p> + +As we mentioned in the introduction of this section, OS type fingerprinting is +currently considered a lower priority, due simply to the numerous ways that +characteristics of the Operating System type may leak into content, and the +comparatively low contribution of OS to overall entropy. In particular, there +are likely to be many ways to measure the differences in widget size, +scrollbar size, and other rendered details on a page. Also, directly exported +OS routines, such as the Math library, expose differences in their +implementations due to these results. + + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +We intend to reduce or eliminate OS type fingerprinting to the best extent +possible, but recognize that the effort for reward on this item is not as high +as other areas. The entropy on the current OS distribution is somewhere around +2 bits, which is much lower than other vectors which can also be used to +fingerprint configuration and user-specific information. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We have no defenses deployed that address OS type fingerprinting, but nothing +else. Several defenses may help also mitigate it, in addition to reducing a +lot more entropy elsewhere. You can see the major areas of OS fingerprinting +we're aware of using the tag <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting-os +on our bugtracker</a>. + </p></li></ol></div></div><p> For more details on identifier linkability bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting tag in our bugtracker</a> </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p> @@ -1333,11 +1362,11 @@ In order to avoid long-term linkability, we provide a "New Identity" context menu option in Torbutton. This context menu option is active if Torbutton can read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36963888"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39106608"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36965136"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39107856"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> First, Torbutton disables Javascript in all open tabs and windows by using both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…" target="_top">browser.docShell.allowJavascript</a> @@ -1382,7 +1411,7 @@ privacy and security issues. Fingerprinting</a> is a statistical attack to attempt to recognize specific encrypted website activity. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36979248"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39122096"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available for classification. This mechanism would either impact the true and false @@ -1404,7 +1433,7 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor network, making them also effectively no-overhead. - </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36986144"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39128912"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…" target="_top">randomize pipeline order and depth</a>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for @@ -1463,7 +1492,7 @@ contend with. For this reason, we have deployed a build system that allows anyone to use our source code to reproduce byte-for-byte identical binary packages to the ones that we distribute. - </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp37001088"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp39143984"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> The GNU toolchain has been working on providing reproducible builds for some time, however a large software project such as Firefox typically ends up @@ -1582,7 +1611,7 @@ container. We addressed umask by setting it explicitly in our Gitian descriptor scriptlet, and addressed the hostname and kernel version leaks by directly patching the aspects of the Firefox build process that included this information into the build. - </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp37036336"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp39178848"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> The build process produces a single sha256sums.txt file that contains a sorted list the SHA-256 hashes of every package produced for that build version. Each @@ -1616,7 +1645,7 @@ and by their nature are based on non-public key material, providing native code-signed packages while still preserving ease of reproducibility verification has not yet been achieved. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp37040272"></a>5.3. Anonymous Verification</h3></div></div></div><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp39182784"></a>5.3. Anonymous Verification</h3></div></div></div><p> Due to the fact that bit-identical packages can be produced by anyone, the security of this build system extends beyond the security of the official @@ -1730,7 +1759,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t ourselves</a>, as they are comparatively rare and can be handled with site permissions. - </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp37071376"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> + </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp39214016"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> Web-Send is a browser-based link sharing and federated login widget that is designed to operate without relying on third-party tracking or abusing other

1 0

[flashproxy/master] use a more flexible wait time in the facilitator test, to work on slower machines
by infinity0＠torproject.org 02 Nov '14

02 Nov '14

commit c89d0c04a6e454c54a58cd17c0b2e7c7267f15fc Author: Ximin Luo <infinity0(a)torproject.org> Date: Sun Nov 2 19:33:55 2014 +0000 use a more flexible wait time in the facilitator test, to work on slower machines --- facilitator/fp-facilitator-test.py | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/facilitator/fp-facilitator-test.py b/facilitator/fp-facilitator-test.py index 9de44d3..8c008a7 100755 --- a/facilitator/fp-facilitator-test.py +++ b/facilitator/fp-facilitator-test.py @@ -209,7 +209,20 @@ class FacilitatorProcTest(unittest.TestCase): self.relay_file.seek(0) fn = os.path.join(os.path.dirname(__file__), "./fp-facilitator") self.process = subprocess.Popen(["python", fn, "-d", "-p", str(FACILITATOR_PORT), "-r", self.relay_file.name, "-l", "/dev/null"]) - time.sleep(0.1) + self.waitForChild() + + def waitForChild(self): + """Wait until the child process is responsive. This takes different + times on different machines so be flexible in how long to wait. e.g. + see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765156""" + for i in xrange(0, 20): + try: + s = fac.fac_socket(FACILITATOR_ADDR) + s.close() + return + except socket.error as e: + time.sleep(0.05) + raise e def tearDown(self): ret = self.process.poll()

1 0

[torspec/master] Note that we will be dropping the "protocol" lines sooner or later
by nickm＠torproject.org 02 Nov '14

02 Nov '14

commit 773f0aea904f0777f5a3e1045a3b2bdfc37e3cd1 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Nov 2 12:37:06 2014 -0500 Note that we will be dropping the "protocol" lines sooner or later (See ticket #13593) --- dir-spec.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dir-spec.txt b/dir-spec.txt index b939139..fb12e27 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -575,6 +575,9 @@ protocols are "Link 1 2 Circuit 1". See section 4.1 of tor-spec.txt for more information about link protocol versions. + [NOTE: No version of Tor uses this protocol list. It will be removed + in a future version of Tor.] + "allow-single-hop-exits" NL [At most once.]

1 0

[tor/master] Refactor the tor_calloc_ overflow check.
by nickm＠torproject.org 02 Nov '14

02 Nov '14

commit aff6fa0b59510471a87a8618ee22327acddf8f86 Author: Mansour Moufid <mansourmoufid(a)gmail.com> Date: Sun Oct 19 12:04:26 2014 -0400 Refactor the tor_calloc_ overflow check. --- src/common/util.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/src/common/util.c b/src/common/util.c index 2371ad3..929eb5f 100644 --- a/src/common/util.c +++ b/src/common/util.c @@ -195,16 +195,19 @@ tor_malloc_zero_(size_t size DMALLOC_PARAMS) return result; } +#define SQRT_SIZE_MAX (((size_t) SIZE_MAX) >> (sizeof(size_t) * 8 / 2)) + +static INLINE int +size_mul_check(const size_t x, const size_t y) +{ + return ((x <= SQRT_SIZE_MAX && y <= SQRT_SIZE_MAX) || + y == 0 || x <= SIZE_MAX / y); +} + /** Allocate a chunk of <b>nmemb</b>*<b>size</b> bytes of memory, fill * the memory with zero bytes, and return a pointer to the result. * Log and terminate the process on error. (Same as * calloc(<b>nmemb</b>,<b>size</b>), but never returns NULL.) - * - * XXXX This implementation probably asserts in cases where it could - * work, because it only tries dividing SIZE_MAX by size (according to - * the calloc(3) man page, the size of an element of the nmemb-element - * array to be allocated), not by nmemb (which could in theory be - * smaller than size). Don't do that then. */ void * tor_calloc_(size_t nmemb, size_t size DMALLOC_PARAMS) @@ -215,13 +218,8 @@ tor_calloc_(size_t nmemb, size_t size DMALLOC_PARAMS) * we're allocating something very big (it knows if it just got the memory * from the OS in a pre-zeroed state). We don't want to use tor_malloc_zero * for big stuff, so we don't bother with calloc. */ - void *result; - size_t max_nmemb = (size == 0) ? SIZE_MAX : SIZE_MAX/size; - - tor_assert(nmemb < max_nmemb); - - result = tor_malloc_zero_((nmemb * size) DMALLOC_FN_ARGS); - return result; + tor_assert(size_mul_check(nmemb, size)); + return tor_malloc_zero_((nmemb * size) DMALLOC_FN_ARGS); } /** Change the size of the memory block pointed to by <b>ptr</b> to <b>size</b>

1 0

← Newer
1
...
89
90
91
92
93
94
95
96
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits November 2014