August 2018 - tor-commits - lists.torproject.org

[exonerator/master] Prepare for 3.0.0 release.
by karsten＠torproject.org 14 Aug '18

14 Aug '18

commit 2612bba5378f8edb53aa8163032f899888c11f56 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Aug 13 19:50:52 2018 +0200 Prepare for 3.0.0 release. --- CHANGELOG.md | 8 +++++--- build.xml | 2 +- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 1faf5ed..dce2f3a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,10 +1,12 @@ -# Changes in version 2.2.0 - 2018-08-?? +# Changes in version 3.0.0 - 2018-08-13 - * Medium changes - - Prepare ExoneraTorServlet for integration into Tor Metrics. + * Major changes - Add a new ExoneraTorRedirectServlet that redirects to Tor Metrics, and make it the default. + * Medium changes + - Prepare ExoneraTorServlet for integration into Tor Metrics. + * Minor changes - Provide a thin jar file without dependencies. diff --git a/build.xml b/build.xml index c28dbcd..9d68d0e 100644 --- a/build.xml +++ b/build.xml @@ -8,7 +8,7 @@ <property name="javadoc-title" value="ExoneraTor API Documentation"/> <property name="implementation-title" value="ExoneraTor" /> - <property name="release.version" value="2.1.0-dev" /> + <property name="release.version" value="3.0.0" /> <property name="metricslibversion" value="2.4.0" /> <property name="jetty.version" value="-9.2.21.v20170120" /> <property name="warfile"

1 0

[tor-browser/tor-browser-60.1.0esr-8.0-1] Bug 26514 - intermittent updater failures on Win64 (Error 19)
by gk＠torproject.org 14 Aug '18

14 Aug '18

commit c2720b2274e51eb76b91e5f6a5f2a82bdfaf8013 Author: Kathy Brade <brade(a)pearlcrescent.com> Date: Mon Aug 13 12:13:40 2018 -0400 Bug 26514 - intermittent updater failures on Win64 (Error 19) Avoid MinGW's _ftelli64() and _fseeki64() implementations because they are unreliable. --- modules/libmar/src/mar_private.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/modules/libmar/src/mar_private.h b/modules/libmar/src/mar_private.h index e0c263271ed0..358026fbcf50 100644 --- a/modules/libmar/src/mar_private.h +++ b/modules/libmar/src/mar_private.h @@ -55,8 +55,15 @@ MOZ_STATIC_ASSERT(sizeof(BLOCKSIZE) < \ instead of the NSPR equivalents. */ #ifdef XP_WIN #include <winsock2.h> +#ifdef __MINGW32__ +/* Avoid MinGW's _ftelli64() and _fseeki64() implementations because they + * are unreliable. See bug #26514. */ +#define ftello ftello64 +#define fseeko fseeko64 +#else #define ftello _ftelli64 #define fseeko _fseeki64 +#endif #else #define _FILE_OFFSET_BITS 64 #include <netinet/in.h>

1 0

[torspec/master] rend-v3: Specify the client authorization file format
by asn＠torproject.org 14 Aug '18

14 Aug '18

commit d0d151989f44c01758e2d9b9834bce29cce693dc Author: David Goulet <dgoulet(a)torproject.org> Date: Thu Jul 12 11:22:55 2018 -0400 rend-v3: Specify the client authorization file format Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- rend-spec-v3.txt | 95 +++++++++++++++++++++++++++----------------------------- 1 file changed, 46 insertions(+), 49 deletions(-) diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index e18f502..4f8afa2 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -2299,15 +2299,17 @@ Appendix F. Hidden service directory format [HIDSERVDIR-FORMAT] This file contains the private master ed25519 key of the onion service. [TODO: Offline keys] - - "./client_authorized_privkeys/" [DIRECTORY] - "./client_authorized_privkeys/alice.keys" [FILE] - "./client_authorized_privkeys/bob.keys" [FILE] - "./client_authorized_privkeys/charlie.keys" [FILE] + - "./authorized_client/" [DIRECTORY] + "./authorized_client/alice" [FILE] + "./authorized_client/bob" [FILE] + "./authorized_client/charlie" [FILE] - If client authorization is _enabled_, this directory MUST contain a file for - each authorized client. Each such file contains the keypair of that client - (if generated by the service), or just the public key of the client (if - generated by the client). See [CLIENT-AUTH-MGMT] for more details. + If client authorization is _enabled_, this directory MUST contain a file + for each authorized client. Each such file contains the public key of the + configured "client-name" transmitted to the service operator by the client. + See [CLIENT-AUTH-MGMT] for more details. + + See section E.1.2 [CLIENT-AUTH-MGMT] for the format of a client file. (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.) @@ -2324,64 +2326,59 @@ Appendix E. Managing authorized client data [CLIENT-AUTH-MGMT] E.1.1. Hidden Service side - A hidden service that wants to perform client authorization, adds a new + A hidden service that wants to perform client authorization, adds the option HiddenServiceAuthorizeClient to its torrc file: - HiddenServiceAuthorizeClient auth-type client-name,client-name,... + HiddenServiceAuthorizeClient <auth-type> <client-name>,... - The only recognized auth-type value is "basic" which describes the scheme in - section [CLIENT-AUTH]. The rest of the line is a comma-separated list of - human-readable authorized client names. + The only recognized auth-type value is "descriptor" which describes the + scheme in section [CLIENT-AUTH]. The rest of the line is a + comma-separated list of human-readable authorized client names. Let's consider that one of the listed client names is "alice". In this - case, Tor checks whether the "./client_authorized_privkeys/alice.keys" - file is present in the filesystem: + case, Tor checks whether the "./authorized_client/alice" file is present + on the filesystem and if found, we use the included keys to authenticate. - If the "alice.keys" file is found, we use the included keys to - authenticate Alice. + E.1.2. Service-side bookkeeping - If no "alice.keys" file is found, Tor is tasked with generating Alice's - keypair. To do so, Tor generates x25519 and ed25519 keypairs for Alice, - then creates the "client_authorized_privkeys/alice.keys" file and writes - the private keys inside. + This section contains more details on how onion services should be + keeping track of the ".keys" file. - In this last case, the hidden service operator has the responsibility to - pass the .key file to Alice in a secure out-of-band way. After the file - is passed to Alice, it can be shredded from the filesystem, as only the - public keys are required for the hidden service to function. + The file contains an ed25519 and x25519 public key for a specific client. + The suggested format is as follow: - E.1.2. Service-side bookkeeping + <auth-type>:<key-type>:<encoded-public-key> - This section contains more details on how onion services should be keeping - track of the ".keys" file. + As an example for the recognized auth type value "descriptor": - In particular, inside a ".keys" file, the onion service should be keeping - track of whether a key is ed25519 or x25519 and whether it's public or - private. An onion service SHOULD have either two private keys (one ed25519 - and one x25519) or two public keys (one ed25519 and one x25519) in its - ".keys" file. The former scenario happens when the service generates the - client auth keys, whereas the latter scenario happens when the client - generates keys themselves and passes them to the service. - - Here is a suggested scheme for "alice.keys" for the latter scenario: - """ - alice - x25519 private c2247870536a192d142d056abefca68d6193158e7c1a59c1654c954eccaff894 - ed25519 private 66c1a77104d86461b6f98f73acf3cd229c80624495d2d74d6fda1e940080a96b - """ + descriptor:x25519:<base64-encoded-pubkey> E.1.3. Client side - A client who wants to register client authorization data for a hidden service - needs to add the following line to their torrc: + A client who wants to register client authorization data for a hidden + service needs to add the following line to their torrc to indicate which + "client-name" is configured to use client authorization. + + HiddenServiceClientAuth <auth-type> <client-name>,... + + That "client-name" is the name of the file that tor will look in the + + HiddenServiceClientAuthDir <DIR> + + The "DIR" contains a file named "client-name" which should be one per + onion address configured with client authorization. + + If "auth-type" is set to "descriptor", the file contains the private key + in binary format: - HidServAuth onion-address x25519-private-key ed25519-private-key + <onion-address>:x25519:<binary private key> - The keys above are either generated by Alice using a key generation utility, - or they are extracted from a ".keys" file provided by the hidden service. + The reason to use a binary representation of the key is to discourage the + user (a human) to try to copy it around or edit the file. - In the former case, the client is also tasked with transfering the public - keys to the hidden service in a secure out-of-band way. + The keypair used for client authorization is created by a third part tool + for which the public key needs to be transferred to the service operator + in a secure out-of-band way. E.2. Configuring client authorization using the control port

1 0

[torspec/master] rend-v3: More improvements to the client auth section.
by asn＠torproject.org 14 Aug '18

14 Aug '18

commit 7b66ac6d80f84abedbaa728f5e75accb14038eb4 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Aug 14 14:12:09 2018 +0300 rend-v3: More improvements to the client auth section. - Add file extension to the client auth files. - Better specify suggested client auth file format. - Suggest better client auth logic for client and service side. --- rend-spec-v3.txt | 101 +++++++++++++++++++++++++++---------------------------- 1 file changed, 49 insertions(+), 52 deletions(-) diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 4f8afa2..1718b22 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -2299,21 +2299,21 @@ Appendix F. Hidden service directory format [HIDSERVDIR-FORMAT] This file contains the private master ed25519 key of the onion service. [TODO: Offline keys] - - "./authorized_client/" [DIRECTORY] - "./authorized_client/alice" [FILE] - "./authorized_client/bob" [FILE] - "./authorized_client/charlie" [FILE] + - "./authorized_clients/" [DIRECTORY] + "./authorized_clients/alice.auth" [FILE] + "./authorized_clients/bob.auth" [FILE] + "./authorized_clients/charlie.auth" [FILE] - If client authorization is _enabled_, this directory MUST contain a file - for each authorized client. Each such file contains the public key of the - configured "client-name" transmitted to the service operator by the client. - See [CLIENT-AUTH-MGMT] for more details. + If client authorization is enabled, this directory MUST contain a ".auth" + file for each authorized client. Each such file contains the public key of + the respective client. The files are transmitted to the service operator by + the client. - See section E.1.2 [CLIENT-AUTH-MGMT] for the format of a client file. + See section [CLIENT-AUTH-MGMT] for more details and the format of the client file. (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.) -Appendix E. Managing authorized client data [CLIENT-AUTH-MGMT] +Appendix G. Managing authorized client data [CLIENT-AUTH-MGMT] Hidden services and clients can configure their authorized client data either using the torrc, or using the control port. This section presents a suggested @@ -2322,67 +2322,64 @@ Appendix E. Managing authorized client data [CLIENT-AUTH-MGMT] (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.) - E.1. Configuring client authorization using torrc + G.1. Configuring client authorization using torrc - E.1.1. Hidden Service side + G.1.1. Hidden Service side configuration - A hidden service that wants to perform client authorization, adds the - option HiddenServiceAuthorizeClient to its torrc file: + A hidden service that wants to enable client authorization, needs to + populate the "authorized_clients/" directory of its HiddenServiceDir + directory with the ".auth" files of its authorized clients. - HiddenServiceAuthorizeClient <auth-type> <client-name>,... + When Tor starts up with a configured onion service, Tor checks its + <HiddenServiceDir>/authorized_clients/ directory for ".auth" files, and if + any recognized and parseable such files are found, then client + authorization becomes activated for that service. - The only recognized auth-type value is "descriptor" which describes the - scheme in section [CLIENT-AUTH]. The rest of the line is a - comma-separated list of human-readable authorized client names. + G.1.2. Service-side bookkeeping - Let's consider that one of the listed client names is "alice". In this - case, Tor checks whether the "./authorized_client/alice" file is present - on the filesystem and if found, we use the included keys to authenticate. + This section contains more details on how onion services should be keeping + track of their client ".auth" files. - E.1.2. Service-side bookkeeping + For the "descriptor" authentication type, the ".auth" file MUST contain + the x25519 public key of that client. Here is a suggested file format: - This section contains more details on how onion services should be - keeping track of the ".keys" file. + <auth-type>:<key-type>:<base32-encoded-public-key> - The file contains an ed25519 and x25519 public key for a specific client. - The suggested format is as follow: + Here is an an example: - <auth-type>:<key-type>:<encoded-public-key> + descriptor:x25519:5c8eac469bb3f1b85bc7cd893f52dc42a9ab66f1b02b5ce6a68e9b175d3bb433 - As an example for the recognized auth type value "descriptor": + Tor SHOULD ignore lines it does not recognize. + Tor SHOULD ignore files that don't use the ".auth" suffix. - descriptor:x25519:<base64-encoded-pubkey> + G.1.3. Client side configuration - E.1.3. Client side + A client who wants to register client authorization data for onion + services needs to add the following line to their torrc to indicate the + directory which hosts ".auth_private" files containing client-side + credentials for onion services: - A client who wants to register client authorization data for a hidden - service needs to add the following line to their torrc to indicate which - "client-name" is configured to use client authorization. + ClientOnionAuthDir <DIR> - HiddenServiceClientAuth <auth-type> <client-name>,... + The <DIR> contains a file with the suffix ".auth_private" for each onion + service the client is authorized with. Tor should scan the directory for + ".auth_private" files to find which onion services require client + authorization from this client. - That "client-name" is the name of the file that tor will look in the + For the "descriptor" auth-type, a ".auth_private" file contains the + private x25519 key: - HiddenServiceClientAuthDir <DIR> + <onion-address>:descriptor:x25519:<base32-encoded-privkey> - The "DIR" contains a file named "client-name" which should be one per - onion address configured with client authorization. - - If "auth-type" is set to "descriptor", the file contains the private key - in binary format: - - <onion-address>:x25519:<binary private key> - - The reason to use a binary representation of the key is to discourage the - user (a human) to try to copy it around or edit the file. - - The keypair used for client authorization is created by a third part tool + The keypair used for client authorization is created by a third party tool for which the public key needs to be transferred to the service operator - in a secure out-of-band way. + in a secure out-of-band way. The third party tool SHOULD add appropriate + headers to the private key file to ensure that users won't accidentally + give out their private key. - E.2. Configuring client authorization using the control port + G.2. Configuring client authorization using the control port - E.2.1. Service side + G.2.1. Service side A hidden service also has the option to configure authorized clients using the control port. The idea is that hidden service operators can use @@ -2397,7 +2394,7 @@ Appendix E. Managing authorized client data [CLIENT-AUTH-MGMT] Hidden services who use the control port interface for client auth need to perform their own key management. - E.2.2. Client side + G.2.2. Client side There should also be a control port interface for clients to register authorization data for hidden services without having to use the

1 0

[torspec/master] rend-v3: Switch to single-file-per-client client auth UX.
by asn＠torproject.org 14 Aug '18

14 Aug '18

commit b7a2685507a7e8b681040933109b9b4f3cd06099 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Jul 10 21:55:54 2018 +0300 rend-v3: Switch to single-file-per-client client auth UX. --- rend-spec-v3.txt | 66 ++++++++++++++++++++++++++++++++------------------------ 1 file changed, 38 insertions(+), 28 deletions(-) diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index dbd3103..e18f502 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -2299,25 +2299,15 @@ Appendix F. Hidden service directory format [HIDSERVDIR-FORMAT] This file contains the private master ed25519 key of the onion service. [TODO: Offline keys] - - "client_authorized_pubkeys" [FILE] - - If client authorization is _enabled_, this is a newline-separated file of - "<client name> <pubkeys> entries for authorized clients. You can think of it - as the ~/.ssh/authorized_keys of onion services. See [CLIENT-AUTH-MGMT] for - more details. - - (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.) - - - "./client_authorized_privkeys/" [DIRECTORY] - "./client_authorized_privkeys/alice.privkey" [FILE] - "./client_authorized_privkeys/bob.privkey" [FILE] - "./client_authorized_privkeys/charlie.privkey" [FILE] + "./client_authorized_privkeys/alice.keys" [FILE] + "./client_authorized_privkeys/bob.keys" [FILE] + "./client_authorized_privkeys/charlie.keys" [FILE] - If client authorization is _enabled_ _AND_ if the hidden service is - responsible for generating and distributing private keys for its clients, - then this directory contains files with client's private keys. See - [CLIENT-AUTH-MGMT] for more details. + If client authorization is _enabled_, this directory MUST contain a file for + each authorized client. Each such file contains the keypair of that client + (if generated by the service), or just the public key of the client (if + generated by the client). See [CLIENT-AUTH-MGMT] for more details. (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.) @@ -2344,23 +2334,43 @@ Appendix E. Managing authorized client data [CLIENT-AUTH-MGMT] human-readable authorized client names. Let's consider that one of the listed client names is "alice". In this - case, Tor checks the "client_authorized_pubkeys" file for any entries - with client_name being "alice". If an "alice" entry is found, we use the - relevant pubkeys to authenticate Alice. + case, Tor checks whether the "./client_authorized_privkeys/alice.keys" + file is present in the filesystem: - If no "alice" entry is found in the "client_authorized_pubkeys" file, Tor - is tasked with generating public/private keys for Alice. To do so, Tor - generates x25519 and ed25519 keypairs for Alice, then makes a - "client_authorized_privkeys/alice.privkey" file and writes the private - keys inside; it also adds an entry for alice to the - "client_authorized_pubkeys" file. + If the "alice.keys" file is found, we use the included keys to + authenticate Alice. + + If no "alice.keys" file is found, Tor is tasked with generating Alice's + keypair. To do so, Tor generates x25519 and ed25519 keypairs for Alice, + then creates the "client_authorized_privkeys/alice.keys" file and writes + the private keys inside. In this last case, the hidden service operator has the responsibility to pass the .key file to Alice in a secure out-of-band way. After the file is passed to Alice, it can be shredded from the filesystem, as only the public keys are required for the hidden service to function. - E.1.2. Client side + E.1.2. Service-side bookkeeping + + This section contains more details on how onion services should be keeping + track of the ".keys" file. + + In particular, inside a ".keys" file, the onion service should be keeping + track of whether a key is ed25519 or x25519 and whether it's public or + private. An onion service SHOULD have either two private keys (one ed25519 + and one x25519) or two public keys (one ed25519 and one x25519) in its + ".keys" file. The former scenario happens when the service generates the + client auth keys, whereas the latter scenario happens when the client + generates keys themselves and passes them to the service. + + Here is a suggested scheme for "alice.keys" for the latter scenario: + """ + alice + x25519 private c2247870536a192d142d056abefca68d6193158e7c1a59c1654c954eccaff894 + ed25519 private 66c1a77104d86461b6f98f73acf3cd229c80624495d2d74d6fda1e940080a96b + """ + + E.1.3. Client side A client who wants to register client authorization data for a hidden service needs to add the following line to their torrc: @@ -2368,7 +2378,7 @@ Appendix E. Managing authorized client data [CLIENT-AUTH-MGMT] HidServAuth onion-address x25519-private-key ed25519-private-key The keys above are either generated by Alice using a key generation utility, - or they are extracted from a .key file provided by the hidden service. + or they are extracted from a ".keys" file provided by the hidden service. In the former case, the client is also tasked with transfering the public keys to the hidden service in a secure out-of-band way.

1 0

[tor-browser/tor-browser-60.1.0esr-8.0-1] Bug 1470156 - Part 1: Adding a test case for reassuring mozilla::OriginAttributes::CreateSuffix won't be crashed with invalid characters in firstParty domain. r=baku, mixedpuppy
by gk＠torproject.org 13 Aug '18

13 Aug '18

commit 82446eff1db658db8dae23443deac036b164b769 Author: Tim Huang <tihuang(a)mozilla.com> Date: Tue Jul 3 13:48:18 2018 +0000 Bug 1470156 - Part 1: Adding a test case for reassuring mozilla::OriginAttributes::CreateSuffix won't be crashed with invalid characters in firstParty domain. r=baku,mixedpuppy Differential Revision: https://phabricator.services.mozilla.com/D1845 --HG-- extra : moz-landing-system : lando --- .../mochitest/test_ext_cookies_first_party.html | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/toolkit/components/extensions/test/mochitest/test_ext_cookies_first_party.html b/toolkit/components/extensions/test/mochitest/test_ext_cookies_first_party.html index 64785c45e440..b214148824bd 100644 --- a/toolkit/components/extensions/test/mochitest/test_ext_cookies_first_party.html +++ b/toolkit/components/extensions/test/mochitest/test_ext_cookies_first_party.html @@ -10,6 +10,8 @@ async function background() { const url = "http://ext-cookie-first-party.mochi.test/"; const firstPartyDomain = "ext-cookie-first-party.mochi.test"; + // A first party domain with invalid characters for the file system, which just happens to be a IPv6 address. + const firstPartyDomainInvalidChars = "[2606:4700:4700::1111]"; const expectedError = "First-Party Isolation is enabled, but the required 'firstPartyDomain' attribute was not set."; const assertExpectedCookies = (expected, cookies, message) => { @@ -154,6 +156,38 @@ async function background() { browser.test.sendMessage("test_fpi_enabled"); }; + // Test FPI with a first party domain with invalid characters for + // the file system. + const test_fpi_with_invalid_characters = async () => { + let cookie; + + // Test setting a cookie with a first party domain with invalid characters + // for the file system. + cookie = await browser.cookies.set({url, name: "foo5", value: "bar5", + firstPartyDomain: firstPartyDomainInvalidChars}); + assertExpectedCookies([ + {name: "foo5", value: "bar5", firstPartyDomain: firstPartyDomainInvalidChars}, + ], [cookie], "set: FPI on, w/ firstPartyDomain with invalid characters, FP cookie"); + + // Test getting a cookie with a first party domain with invalid characters + // for the file system. + cookie = await browser.cookies.get({url, name: "foo5", + firstPartyDomain: firstPartyDomainInvalidChars}); + assertExpectedCookies([ + {name: "foo5", value: "bar5", firstPartyDomain: firstPartyDomainInvalidChars}, + ], [cookie], "get: FPI on, w/ firstPartyDomain with invalid characters, FP cookie"); + + // Test removing a cookie with a first party domain with invalid characters + // for the file system. + cookie = await browser.cookies.remove({url, name: "foo5", + firstPartyDomain: firstPartyDomainInvalidChars}); + assertExpectedCookies([ + {url, name: "foo5", firstPartyDomain: firstPartyDomainInvalidChars}, + ], [cookie], "remove: FPI on, w/ firstPartyDomain with invalid characters, FP cookie"); + + browser.test.sendMessage("test_fpi_with_invalid_characters"); + }; + // Test when FPI is disabled again, accessing FP cookies set when FPI is enabled. const test_fpd_cookies_on_fpi_disabled = async () => { let cookie, cookies; @@ -179,6 +213,7 @@ async function background() { switch (message) { case "test_fpi_disabled": return test_fpi_disabled(); case "test_fpi_enabled": return test_fpi_enabled(); + case "test_fpi_with_invalid_characters": return test_fpi_with_invalid_characters(); case "test_fpd_cookies_on_fpi_disabled": return test_fpd_cookies_on_fpi_disabled(); default: return browser.test.notifyFail("unknown-message"); } @@ -210,6 +245,8 @@ add_task(async () => { await enableFirstPartyIsolation(); extension.sendMessage("test_fpi_enabled"); await extension.awaitMessage("test_fpi_enabled"); + extension.sendMessage("test_fpi_with_invalid_characters"); + await extension.awaitMessage("test_fpi_with_invalid_characters"); await disableFirstPartyIsolation(); extension.sendMessage("test_fpd_cookies_on_fpi_disabled"); await extension.awaitMessage("test_fpd_cookies_on_fpi_disabled");

1 0

[tor-browser/tor-browser-60.1.0esr-8.0-1] Bug 1470156 - Part 2: Fixing the crashing problem when using an invalid character in a firstPartyDomain. r=baku
by gk＠torproject.org 13 Aug '18

13 Aug '18

commit 7d9decc785bdc42443ee9835e0244f082d6911fb Author: Tim Huang <tihuang(a)mozilla.com> Date: Tue Jul 3 13:47:45 2018 +0000 Bug 1470156 - Part 2: Fixing the crashing problem when using an invalid character in a firstPartyDomain. r=baku This patch adds a sanitization of firstPartyDomain when calling the OriginAttributes::CreateSuffix() and remove the release assert there. The cookies API for the web extension can use a arbitrary string for the firstPartyDomain. So, we should sanitize the firstPartyDomain before we creating a suffix. The release assert is not required anymore since the firstPartyDomain is sanitized Depends on D1845. Differential Revision: https://phabricator.services.mozilla.com/D1856 --HG-- extra : moz-landing-system : lando --- caps/OriginAttributes.cpp | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/caps/OriginAttributes.cpp b/caps/OriginAttributes.cpp index ea3d7e507f3f..21092e46fb74 100644 --- a/caps/OriginAttributes.cpp +++ b/caps/OriginAttributes.cpp @@ -151,8 +151,10 @@ OriginAttributes::CreateSuffix(nsACString& aStr) const } if (!mFirstPartyDomain.IsEmpty()) { - MOZ_RELEASE_ASSERT(mFirstPartyDomain.FindCharInSet(dom::quota::QuotaManager::kReplaceChars) == kNotFound); - params.Set(NS_LITERAL_STRING("firstPartyDomain"), mFirstPartyDomain); + nsAutoString sanitizedFirstPartyDomain(mFirstPartyDomain); + sanitizedFirstPartyDomain.ReplaceChar(dom::quota::QuotaManager::kReplaceChars, '+'); + + params.Set(NS_LITERAL_STRING("firstPartyDomain"), sanitizedFirstPartyDomain); } aStr.Truncate();

1 0

[tor-browser/tor-browser-60.1.0esr-8.0-1] Bug 1473247 - Part 1: Fixing the issue that the IP addresses won't be set for first party domains. r=arthuredelstein, baku
by gk＠torproject.org 13 Aug '18

13 Aug '18

commit a8a7f63745d822670462bde4c8db8cbb2ccc397c Author: Tim Huang <tihuang(a)mozilla.com> Date: Fri Jul 13 19:53:15 2018 +0000 Bug 1473247 - Part 1: Fixing the issue that the IP addresses won't be set for first party domains. r=arthuredelstein,baku Right now, the firstPartyDomain won't be set when using IP addresses as first party domains. It is because of that the TLD service won't accept IP addresses as valid hosts. The patch fixes this problem by detecting that if the host is a IP address. If it is, we will still set the firstPartyDoamin with the IP address. Differential Revision: https://phabricator.services.mozilla.com/D1977 --HG-- extra : moz-landing-system : lando --- caps/OriginAttributes.cpp | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/caps/OriginAttributes.cpp b/caps/OriginAttributes.cpp index 3d9c3f9bda78..ea3d7e507f3f 100644 --- a/caps/OriginAttributes.cpp +++ b/caps/OriginAttributes.cpp @@ -11,6 +11,7 @@ #include "nsIEffectiveTLDService.h" #include "nsIURI.h" #include "nsIURIWithPrincipal.h" +#include "nsURLHelper.h" namespace mozilla { @@ -58,6 +59,28 @@ OriginAttributes::SetFirstPartyDomain(const bool aIsTopLevelDocument, return; } + if (rv == NS_ERROR_HOST_IS_IP_ADDRESS) { + // If the host is an IPv4/IPv6 address, we still accept it as a + // valid firstPartyDomain. + nsAutoCString ipAddr; + rv = aURI->GetHost(ipAddr); + NS_ENSURE_SUCCESS_VOID(rv); + + if (net_IsValidIPv6Addr(ipAddr.BeginReading(), ipAddr.Length())) { + // According to RFC2732, the host of an IPv6 address should be an + // IPv6reference. The GetHost() of nsIURI will only return the IPv6 + // address. So, we need to convert it back to IPv6reference here. + mFirstPartyDomain.Truncate(); + mFirstPartyDomain.AssignLiteral("["); + mFirstPartyDomain.Append(NS_ConvertUTF8toUTF16(ipAddr)); + mFirstPartyDomain.AppendLiteral("]"); + } else { + mFirstPartyDomain = NS_ConvertUTF8toUTF16(ipAddr); + } + + return; + } + nsAutoCString scheme; rv = aURI->GetScheme(scheme); NS_ENSURE_SUCCESS_VOID(rv);

1 0

[tor-browser/tor-browser-60.1.0esr-8.0-1] Bug 1473247 - Part 2: Add a test case for making sure that IP addresses can work properly for the firstPartyDomain. r=arthuredelstein, baku
by gk＠torproject.org 13 Aug '18

13 Aug '18

commit a75945d96b2d8903a86ac1c9016a8d300028b79f Author: Tim Huang <tihuang(a)mozilla.com> Date: Fri Jul 13 19:55:02 2018 +0000 Bug 1473247 - Part 2: Add a test case for making sure that IP addresses can work properly for the firstPartyDomain. r=arthuredelstein,baku Differential Revision: https://phabricator.services.mozilla.com/D1978 --HG-- extra : moz-landing-system : lando --- .../test/browser/browser_firstPartyIsolation.js | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/browser/components/originattributes/test/browser/browser_firstPartyIsolation.js b/browser/components/originattributes/test/browser/browser_firstPartyIsolation.js index 560de8c8f572..06bc21255a94 100644 --- a/browser/components/originattributes/test/browser/browser_firstPartyIsolation.js +++ b/browser/components/originattributes/test/browser/browser_firstPartyIsolation.js @@ -278,3 +278,22 @@ add_task(async function window_open_form_test() { gBrowser.removeTab(tab); await BrowserTestUtils.closeWindow(win); }); + +/** + * A test for using an IP address as the first party domain. + */ +add_task(async function ip_address_test() { + const ipAddr = "127.0.0.1"; + const ipHost = `http://${ipAddr}/browser/browser/components/originattributes/test/browser/`; + + let tab = BrowserTestUtils.addTab(gBrowser, ipHost + "test_firstParty.html"); + await BrowserTestUtils.browserLoaded(tab.linkedBrowser, true); + + await ContentTask.spawn(tab.linkedBrowser, { firstPartyDomain: ipAddr }, async function(attrs) { + info("document principal: " + content.document.nodePrincipal.origin); + Assert.equal(content.document.nodePrincipal.originAttributes.firstPartyDomain, + attrs.firstPartyDomain, "The firstPartyDomain should be set properly for the IP address"); + }); + + gBrowser.removeTab(tab); +});

1 0

[torbutton/master] Bug 26655: Adjust color and size of onion button
by gk＠torproject.org 13 Aug '18

13 Aug '18

commit e9b4af29d8acf595bd0da4253336db0783ad5b24 Author: Georg Koppen <gk(a)torproject.org> Date: Mon Aug 13 13:18:25 2018 +0000 Bug 26655: Adjust color and size of onion button Icon design by Antonela Debiasi. --- src/chrome/skin/torbutton-update-needed.svg | 16 +++++++++------- src/chrome/skin/torbutton.svg | 10 +++++----- 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/src/chrome/skin/torbutton-update-needed.svg b/src/chrome/skin/torbutton-update-needed.svg index 73f819ec..12bcca31 100644 --- a/src/chrome/skin/torbutton-update-needed.svg +++ b/src/chrome/skin/torbutton-update-needed.svg @@ -1,11 +1,13 @@ <?xml version="1.0" encoding="UTF-8"?> -<svg width="24px" height="24px" viewBox="0 0 24 24" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> - <g id="Icon---Tor---Update" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd"> - <g id="Tor-Button-Icon" transform="translate(2.000000, 1.000000)" fill="#0C0C0D"> - <path d="M8.27206791,6.27905236 C7.88283063,6.53485117 6.37928571,7.48491742 6.38222311,7.48303971 C5.92467564,7.77552366 5.55774616,8.01739321 5.22956304,8.24495813 C4.62774003,8.66226724 4.1902024,9.01032507 3.90524298,9.30237927 C2.34845165,10.8521114 1.86583368,12.1863028 2.03292037,14.2840468 C2.17744778,16.6290092 3.98280543,18.7226974 6.62789966,19.5725823 C7.66430091,19.8978216 8.64783036,20 10.3045058,20 C12.4566798,20 14.4305353,19.426444 15.7257727,18.390024 C17.1602235,17.2499732 18,15.5258216 18,13.7581121 C18,11.9676824 17.2065463,10.2463814 15.7919239,9.00433992 C15.0624549,8.37501782 14.1112169,7.77509114 12.728283,7.03810567 C11.4758566,6.39901667 10.3718516,5.26209475 9.95586156,3.83344263 C9.74417905,4.87665258 9.16812751,5.7299448 8.27206791,6.27905236 Z M17.1048177,7.49557522 C18.9563878,9.1179941 20,11.3893805 20,13.7581121 C20,16.1268437 18.889058,18.4306785 16.9701581,19.9557522 C15.1859178,21.3834808 12.6947145,22 10.3045058,22 C8.8232498,22 7.47 665339,21.9351032 6.02906225,21.480826 C2.69623613,20.4100295 0.238697687,17.6843658 0.0367082257,14.4070796 C-0.165281236,11.8761062 0.440687149,9.92920354 2.49424667,7.88495575 C3.53785889,6.81415929 5.69241315,5.58112094 7.1736692,4.60766962 C7.91429722,4.15339233 8.68859016,2.79056047 7.20733411,0.227138643 L7.5103183,0 L11.9204215,1.75221239 C11.3144532,3.63421829 13.0650285,4.96460177 13.637332,5.25663717 C14.9165986,5.9380531 16.1285353,6.6519174 17.1048177,7.49557522 Z" id="Border" fill-rule="nonzero"></path> - <path d="M10,5.80000019 C10.3632315,6.90320629 11.2333653,7.78038283 12.2159038,8.28105702 C13.3397544,8.87914153 14.1127842,9.36599897 14.7055922,9.87671162 C15.8551945,10.8846633 16.5,12.2815477 16.5,13.7345319 C16.5,15.1690781 15.81755,16.5682758 14.6518339,17.4934592 C13.5992506,18.3345433 11.9951837,18.8000002 10.2462051,18.8000002 C10.1620472,18.8000002 10.0800269,18.7996762 10,18.7990042 L10,5.80000019 Z" id="Half-Content"></path> +<svg width="16px" height="16px" viewBox="0 0 16 16" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> + <g id="Icon---Tor-Update---Grey" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd"> + <g id="Tor-Button-Icon" fill="#0C0C0D" fill-opacity="0.8"> + <path d="M7.06561268,5.02241519 C6.77772045,5.2116121 5.67952408,5.90554501 5.6853992,5.90178938 C5.35790364,6.11113858 5.09635335,6.28354515 4.86413018,6.44457064 C4.45268439,6.72987059 4.15887546,6.96359333 3.97499388,7.15193679 C2.95731966,8.16499644 2.66333288,8.97771922 2.77290903,10.3548433 C2.86347409,11.8242645 4.01769529,13.1628244 5.73360996,13.7141752 C6.42393225,13.9308094 7.08993386,14 8.24418607,14 C9.69409954,14 11.010192,13.6175745 11.8475477,12.9475461 C12.7611494,12.2214478 13.2954545,11.1244618 13.2954545,10.0058997 C13.2954545,8.86286776 12.7876949,7.76058164 11.8769727,6.9600938 C11.3838667,6.53505399 10.722397,6.11798563 9.75901067,5.60447735 C9.08955454,5.26286683 8.4719792,4.75203246 8.02479915,4.11379651 C7.77978416,4.4739196 7.45874047,4.78154253 7.06561268,5.02241519 Z M13.1898674,5.45132743 C14.5364638,6.63126844 15.2954545,8.28318584 15.2954545,10.0058997 C15.2954545,11.7286136 14.4874967,13.4041298 13.0919331,14.5132743 C11.7943039,15.551622 4 9.98251962,16 8.24418607,16 C7.16690894,16 6.1875661,15.9528024 5.13477254,15.6224189 C2.71089901,14.8436578 0.923598318,12.8613569 0.776696891,10.4778761 C0.629795465,8.63716814 1.07049974,7.22123894 2.56399758,5.73451327 C3.32298828,4.95575221 4.88993683,4.05899705 5.96721396,3.35103245 C6.50585253,3.02064897 7.06897466,2.02949853 5.99169753,0.16519174 L6.21204967,0 L9.41939748,1.27433628 C8.97869321,2.64306785 10.2518389,3.61061947 10.6680596,3.82300885 C11.5984353,4.31858407 12.4798439,4.83775811 13.1898674,5.45132743 Z" id="Border" fill-rule="nonzero"></path> + <path d="M8.27272727,5 C8.49625435,5.67889606 9.03172133,6.21869701 9.63636041,6.5268042 C10.3279607,6.89485621 10.8036714,7.19446079 11.1684763,7.5087455 C11.8759239,8.12902347 12.2727273,8.98864463 12.2727273,9.88278877 C12.2727273,10.7655864 11.852758,11.6266312 11.1353943,12.1959748 C10.4876507,12.713565 9.5005326,13 8.42423809,13 C8.37244863,13 8.32197458,12.9998006 8.27272727,12.9993871 L8.27272727,5 Z" id="Half-Content"></path> + </g> + <g id="!" transform="translate(0.000000, 6.100000)"> + <polygon id="Triangle-Copy" fill="#414141" points="5 0.714285714 9.28571429 9.28571429 0.714285714 9.28571429"></polygon> + <path d="M9.78067261,7.86561722 C10.0020131,8.30856238 9.97819173,8.83453755 9.71771774,9.25566142 C9.45724375,9.6767853 8.9972698,9.93299087 8.50210118,9.93276007 L1.42710118,9.93276007 C0.932880889,9.93225088 0.474029854,9.67633171 0.213899592,9.2561101 C-0.0462306709,8.83588849 -0.0706843715,8.31106384 0.149244037,7.86847436 L3.68710118,0.789902932 C3.92904842,0.305811394 4.42377158,0 4.96495832,0 C5.50614506,0 6.00086822,0.305811394 6.24281547,0.789902932 L9.78067261,7.86561722 Z M4.25067261,2.78990293 L4.25067261,5.64704579 C4.25067261,6.0415349 4.57046922,6.3613315 4.96495832,6.3613315 C5.35944743,6.3613315 5.67924404,6.0415349 5.67924404,5.64704579 L5.67924404,2.78990293 C5.67924404,2.39541382 5.35944743,2.07561722 4.96495832,2.07561722 C4.57046922,2.07561722 4.25067261,2.39541382 4.25067261,2.78990293 Z M4.96495832,8.68276007 C5.45806971,8.68276007 5.85781547,8.28301432 5.85781547,7.78990293 C5.85781547,7.29679155 5.45806971,6.89704579 4.96495832,6.89704579 C4.47 184694,6.89704579 4.07210118,7.29679155 4.07210118,7.78990293 C4.07210118,8.28301432 4.47184694,8.68276007 4.96495832,8.68276007 Z" id="Shape-Copy" fill="#FFE900" fill-rule="nonzero"></path> </g> - <polygon id="Triangle" fill="#0C0C0D" points="7 11 13 23 1 23"></polygon> - <path d="M13.6929417,21.0118641 C14.0028183,21.6319873 13.9694684,22.3683526 13.6048048,22.957926 C13.2401412,23.5474994 12.5961777,23.9061872 11.9029417,23.9058641 L1.99794165,23.9058641 C1.30603325,23.9051512 0.663641796,23.5468644 0.299459428,22.9585541 C-0.0647229393,22.3702439 -0.0989581202,21.6354894 0.208941651,21.0158641 L5.16194165,11.1058641 C5.50066779,10.428136 6.19328022,10 6.95094165,10 C7.70860308,10 8.40121551,10.428136 8.73994165,11.1058641 L13.6929417,21.0118641 Z M5.95094165,13.9058641 L5.95094165,17.9058641 C5.95094165,18.4581489 6.3986569,18.9058641 6.95094165,18.9058641 C7.5032264,18.9058641 7.95094165,18.4581489 7.95094165,17.9058641 L7.95094165,13.9058641 C7.95094165,13.3535794 7.5032264,12.9058641 6.95094165,12.9058641 C6.3986569,12.9058641 5.95094165,13.3535794 5.95094165,13.9058641 Z M6.95094165,22.1558641 C7.64129759,22.1558641 8.20094165,21.59622 8.20094165,20.9058641 C8.20094165,20.2155082 7.64129759,19.6558641 6.95094165,19.6558641 C6.26058571, 19.6558641 5.70094165,20.2155082 5.70094165,20.9058641 C5.70094165,21.59622 6.26058571,22.1558641 6.95094165,22.1558641 Z" id="Shape" fill="#FFE900" fill-rule="nonzero"></path> </g> </svg> diff --git a/src/chrome/skin/torbutton.svg b/src/chrome/skin/torbutton.svg index 518e981d..11892c6f 100644 --- a/src/chrome/skin/torbutton.svg +++ b/src/chrome/skin/torbutton.svg @@ -1,9 +1,9 @@ <?xml version="1.0" encoding="UTF-8"?> -<svg width="24px" height="24px" viewBox="0 0 24 24" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> - <g id="Icon---Tor-" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd"> - <g id="Tor-Button-Icon" transform="translate(2.000000, 1.000000)" fill="#0C0C0D"> - <path d="M8.27206791,6.27905236 C7.88283063,6.53485117 6.37928571,7.48491742 6.38222311,7.48303971 C5.92467564,7.77552366 5.55774616,8.01739321 5.22956304,8.24495813 C4.62774003,8.66226724 4.1902024,9.01032507 3.90524298,9.30237927 C2.34845165,10.8521114 1.86583368,12.1863028 2.03292037,14.2840468 C2.17744778,16.6290092 3.98280543,18.7226974 6.62789966,19.5725823 C7.66430091,19.8978216 8.64783036,20 10.3045058,20 C12.4566798,20 14.4305353,19.426444 15.7257727,18.390024 C17.1602235,17.2499732 18,15.5258216 18,13.7581121 C18,11.9676824 17.2065463,10.2463814 15.7919239,9.00433992 C15.0624549,8.37501782 14.1112169,7.77509114 12.728283,7.03810567 C11.4758566,6.39901667 10.3718516,5.26209475 9.95586156,3.83344263 C9.74417905,4.87665258 9.16812751,5.7299448 8.27206791,6.27905236 Z M17.1048177,7.49557522 C18.9563878,9.1179941 20,11.3893805 20,13.7581121 C20,16.1268437 18.889058,18.4306785 16.9701581,19.9557522 C15.1859178,21.3834808 12.6947145,22 10.3045058,22 C8.8232498,22 7.47 665339,21.9351032 6.02906225,21.480826 C2.69623613,20.4100295 0.238697687,17.6843658 0.0367082257,14.4070796 C-0.165281236,11.8761062 0.440687149,9.92920354 2.49424667,7.88495575 C3.53785889,6.81415929 5.69241315,5.58112094 7.1736692,4.60766962 C7.91429722,4.15339233 8.68859016,2.79056047 7.20733411,0.227138643 L7.5103183,0 L11.9204215,1.75221239 C11.3144532,3.63421829 13.0650285,4.96460177 13.637332,5.25663717 C14.9165986,5.9380531 16.1285353,6.6519174 17.1048177,7.49557522 Z" id="Border" fill-rule="nonzero"></path> - <path d="M10,5.80000019 C10.3632315,6.90320629 11.2333653,7.78038283 12.2159038,8.28105702 C13.3397544,8.87914153 14.1127842,9.36599897 14.7055922,9.87671162 C15.8551945,10.8846633 16.5,12.2815477 16.5,13.7345319 C16.5,15.1690781 15.81755,16.5682758 14.6518339,17.4934592 C13.5992506,18.3345433 11.9951837,18.8000002 10.2462051,18.8000002 C10.1620472,18.8000002 10.0800269,18.7996762 10,18.7990042 L10,5.80000019 Z" id="Half-Content"></path> +<svg width="16px" height="16px" viewBox="0 0 16 16" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> + <g id="Icon---Tor---Grey" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd" fill-opacity="0.8"> + <g id="Tor-Button-Icon" fill="#0C0C0D"> + <path d="M7.06561268,5.02241519 C6.77772045,5.2116121 5.67952408,5.90554501 5.6853992,5.90178938 C5.35790364,6.11113858 5.09635335,6.28354515 4.86413018,6.44457064 C4.45268439,6.72987059 4.15887546,6.96359333 3.97499388,7.15193679 C2.95731966,8.16499644 2.66333288,8.97771922 2.77290903,10.3548433 C2.86347409,11.8242645 4.01769529,13.1628244 5.73360996,13.7141752 C6.42393225,13.9308094 7.08993386,14 8.24418607,14 C9.69409954,14 11.010192,13.6175745 11.8475477,12.9475461 C12.7611494,12.2214478 13.2954545,11.1244618 13.2954545,10.0058997 C13.2954545,8.86286776 12.7876949,7.76058164 11.8769727,6.9600938 C11.3838667,6.53505399 10.722397,6.11798563 9.75901067,5.60447735 C9.08955454,5.26286683 8.4719792,4.75203246 8.02479915,4.11379651 C7.77978416,4.4739196 7.45874047,4.78154253 7.06561268,5.02241519 Z M13.1898674,5.45132743 C14.5364638,6.63126844 15.2954545,8.28318584 15.2954545,10.0058997 C15.2954545,11.7286136 14.4874967,13.4041298 13.0919331,14.5132743 C11.7943039,15.551622 4 9.98251962,16 8.24418607,16 C7.16690894,16 6.1875661,15.9528024 5.13477254,15.6224189 C2.71089901,14.8436578 0.923598318,12.8613569 0.776696891,10.4778761 C0.629795465,8.63716814 1.07049974,7.22123894 2.56399758,5.73451327 C3.32298828,4.95575221 4.88993683,4.05899705 5.96721396,3.35103245 C6.50585253,3.02064897 7.06897466,2.02949853 5.99169753,0.16519174 L6.21204967,0 L9.41939748,1.27433628 C8.97869321,2.64306785 10.2518389,3.61061947 10.6680596,3.82300885 C11.5984353,4.31858407 12.4798439,4.83775811 13.1898674,5.45132743 Z" id="Border" fill-rule="nonzero"></path> + <path d="M8.27272727,5 C8.49625435,5.67889606 9.03172133,6.21869701 9.63636041,6.5268042 C10.3279607,6.89485621 10.8036714,7.19446079 11.1684763,7.5087455 C11.8759239,8.12902347 12.2727273,8.98864463 12.2727273,9.88278877 C12.2727273,10.7655864 11.852758,11.6266312 11.1353943,12.1959748 C10.4876507,12.713565 9.5005326,13 8.42423809,13 C8.37244863,13 8.32197458,12.9998006 8.27272727,12.9993871 L8.27272727,5 Z" id="Half-Content"></path> </g> </g> </svg>

1 0