April 2016 - tor-commits - lists.torproject.org

[torspec/master] prop224: Various improvements.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 397244ffecd091b841307c710aa8f8c3d6483818 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Mar 15 14:02:28 2016 +0200 prop224: Various improvements. - Kill last remnants of TAP from the proposal. - Replace SHA256 with SHA3-256 and our KDF with SHAKE. - Make the INTRO_ESTABLISHED cell extensible. - Improve the descriptor format a bit. - Don't be ambiguous about "INTRODUCE" cells (pointed out by malekbr). - Cleanup the scaling section. --- proposals/224-rend-spec-ng.txt | 91 ++++++++++++++++-------------------------- 1 file changed, 35 insertions(+), 56 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 78b2071..dd76e36 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -137,11 +137,11 @@ Status: Draft * Instantiate PK with Curve25519. - * Instantiate H with SHA256. [TODO: really?] + * Instantiate H with SHA3-256. - * Instantiate MAC with HMAC using H. + * Instantiate MAC(key=k, message=m) with H(k || m). - * Instantiate KDF with HKDF using H. + * Instantiate KDF with HKDF using SHAKE-256. For legacy purposes, we specify compatibility with older versions of the Tor introduction point and rendezvous point protocols. These used @@ -431,31 +431,12 @@ Status: Draft 1.5. In more detail: Scaling to multiple hosts - [THIS SECTION IS UNFINISHED] - - In order to allow multiple hosts to provide a single hidden service, - I'm considering two options. - - * We can have each server build an introduction circuit to each - introduction point, and have the introduction points responsible - for round-robining between these circuits. One service host is - responsible for picking the introduction points and publishing - the descriptors. - - * We can have servers choose their introduction points - independently, and build circuits to them. One service host is - responsible for combining these introduction points into a - single descriptor. - - If we want to avoid having a single "master" host without which the - whole service goes down (the "one service host" in the description - above), we need a way to fail over from one host to another. We also - need a way to coordinate between the hosts. This is as yet - undesigned. Maybe it should use a hidden service? - - See [SCALING-REFS] for discussion on this topic. - - [TODO: Finalize this design.] + This design is compatible with our current approaches for scaling hidden + services. Specifically, hidden service operators can use onionbalance to + achieve high availability between multiple nodes on the HSDir + layer. Furthermore, operators can use proposal 255 to load balance their + hidden services on the introduction layer. See [SCALING-REFS] for further + discussions on this topic and alternative designs. 1.6. In more detail: Backward compatibility with older hidden service protocols @@ -839,13 +820,17 @@ Status: Draft The format for a hidden service descriptor is as follows, using the meta-format from dir-spec.txt. - "hs-descriptor" SP version-number SP certificate NL + "hs-descriptor" SP version-number NL [At start, exactly once.] The version-number contains a positive integer indicating the version of the descriptor. Current version is "3". + "descriptor-signing-key-cert" SP certificate NL + + [Exactly once.] + The 'certificate' field contains a certificate in the format from proposal 220, with the short-term ed25519 descriptor-signing key for the replica, signed by the blinded public key for the replica. @@ -1089,7 +1074,7 @@ Status: Draft [00, 01] -- Reserved for legacy introduction cells; see [LEGACY_EST_INTRO below] - [02] -- Ed25519; HMAC-SHA256. + [02] -- Ed25519; SHA3-256. [FF] -- Reserved for maintenance messages on existing circuits; see MAINT_INTRO below. @@ -1155,22 +1140,14 @@ Status: Draft The KEY field is a ASN1-encoded RSA public key. - The HANDSHAKE_AUTH field contains the SHA1 digest of (KH | - "INTRODUCE"). + The HANDSHAKE_AUTH field contains the SHA1 digest of (KH | "INTRODUCE"). The SIG field contains an RSA signature, using PKCS1 padding, of all earlier fields. - Note that since the relay payload itself may be no more than 498 - bytes long, the KEY_LEN field can never have a first byte other - than [00] or [01]. These values are used to distinguish legacy - ESTABLISH_INTRO cells from newer ones. - - Older versions of Tor always use a 1024-bit RSA key for these - introduction authentication keys. - - Newer hidden services MAY use RSA keys up 1904 bits. Any more than - that will not fit in a RELAY cell payload. + Older versions of Tor always use a 1024-bit RSA key for these introduction + authentication keys. Newer hidden services MAY use RSA keys up 1904 + bits. Any more than that will not fit in a RELAY cell payload. 3.1.3. Managing introduction circuits [MAINT_INTRO] @@ -1242,12 +1219,16 @@ Status: Draft 3.1.4. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] - After setting up an introduction circuit, the introduction point - reports its status back to the hidden service host with an empty - INTRO_ESTABLISHED cell. + After setting up an introduction circuit, the introduction point reports its + status back to the hidden service host with an INTRO_ESTABLISHED cell. + + The INTRO_ESTABLISHED cell has the following contents: - [TODO: make this cell type extensible. It should be able to include - data if that turns out to be needed.] + N_EXTENSIONS [1 byte] + N_EXTENSIONS times: + EXT_FIELD_TYPE [1 byte] + EXT_FIELD_LEN [1 byte] + EXT_FIELD [EXT_FIELD_LEN bytes] 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] @@ -1400,10 +1381,9 @@ Status: Draft doesn't recognize; instead, it should use them verbatim in its EXTEND request to the rendezvous point. - The ONION_KEY_TYPE field is one of: + The ONION_KEY_TYPE field is: - [01] TAP-RSA-1024: ONION_KEY is 128 bytes long. - [02] NTOR: ONION_KEY is 32 bytes long. + [01] NTOR: ONION_KEY is 32 bytes long. The ONION_KEY field describes the onion key that must be used when extending to the rendezvous point. It must be of a type listed as @@ -1450,14 +1430,13 @@ Status: Draft Notation here is as in section 5.1.4 of tor-spec.txt, which defines the ntor handshake. - The PROTOID for this variant is - "hidden-service-ntor-curve25519-sha256-1". Define the tweak value - t_hsenc, and the tag value m_hsexpand as: + The PROTOID for this variant is "tor-hs-ntor-curve25519-sha3-256-1". + We also use the following tweak values: t_hsenc = PROTOID | ":hs_key_extract" m_hsexpand = PROTOID | ":hs_key_expand" - To make an INTRODUCE cell, the client must know a public encryption + To make an INTRODUCE1 cell, the client must know a public encryption key B for the hidden service on this introduction circuit. The client generates a single-use keypair: x,X = KEYGEN() @@ -1560,7 +1539,7 @@ Status: Draft 3.4.1. Password-based authentication. To authenticate with a password, the user must include an extension - field in the encrypted part of the INTRODUCE cell with an + field in the encrypted part of the INTRODUCE1 cell with an EXT_FIELD_TYPE type of [01] and the contents: Username [00] Password. @@ -1573,7 +1552,7 @@ Status: Draft 3.4.2. Ed25519-based authentication. To authenticate with an Ed25519 private key, the user must include an - extension field in the encrypted part of the INTRODUCE cell with an + extension field in the encrypted part of the INTRODUCE1 cell with an EXT_FIELD_TYPE type of [02] and the contents: Nonce [16 bytes]

1 0

[torspec/master] prop224: Fix undefined variables in the ntor section.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 191e93cc6e0a126006c61b3eb3f46f4491c6a6af Author: George Kadianakis <desnacked(a)riseup.net> Date: Fri Apr 8 19:15:14 2016 +0300 prop224: Fix undefined variables in the ntor section. --- proposals/224-rend-spec-ng.txt | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index d80b2d5..8e14e2a 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1445,6 +1445,8 @@ Status: Draft We also use the following tweak values: t_hsenc = PROTOID | ":hs_key_extract" + t_hsverify = PROTOID | ":hs_verify" + t_hsmac = PROTOID | ":hs_mac" m_hsexpand = PROTOID | ":hs_key_expand" To make an INTRODUCE1 cell, the client must know a public encryption @@ -1454,8 +1456,7 @@ Status: Draft and computes: secret_hs_input = EXP(B,x) | AUTH_KEYID | X | B | PROTOID info = m_hsexpand | subcredential - hs_keys = HKDF(secret_hs_input, t_hsenc, info, - S_KEY_LEN+MAC_LEN) + hs_keys = HKDF(secret_hs_input, t_hsenc, info, S_KEY_LEN+MAC_LEN) ENC_KEY = hs_keys[0:S_KEY_LEN] MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN] @@ -1510,31 +1511,28 @@ Status: Draft service host generates a keypair of y,Y = KEYGEN(), and uses its introduction point encryption key 'b' to computes: - xb = EXP(X,b) - - secret_hs_input = xb | AUTH_KEYID | X | B | PROTOID + secret_hs_input = EXP(X,b) | AUTH_KEYID | X | B | PROTOID info = m_hsexpand | subcredential - hs_keys = HKDF(secret_hs_input, t_hsenc, info, - S_KEY_LEN+MAC_LEN) + hs_keys = HKDF(secret_hs_input, t_hsenc, info, S_KEY_LEN+MAC_LEN) HS_DEC_KEY = hs_keys[0:S_KEY_LEN] HS_MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN] (The above are used to check the MAC and then decrypt the encrypted data.) - ntor_secret_input = EXP(X,y) | xb | ID | B | X | Y | PROTOID - NTOR_KEY_SEED = H(secret_input, t_key) - verify = H(secret_input, t_verify) - auth_input = verify | ID | B | Y | X | PROTOID | "Server" + ntor_secret_input = EXP(X,y) | EXP(X,b) | AUTH_KEYID | B | X | Y | PROTOID + NTOR_KEY_SEED = MAC(ntor_secret_input, t_hsenc) + verify = MAC(ntor_secret_input, t_hsverify) + auth_input = verify | AUTH_KEYID | B | Y | X | PROTOID | "Server" (The above are used to finish the ntor handshake.) The server's handshake reply is: - SERVER_PK Y [G_LEN bytes] - AUTH H(auth_input, t_mac) [H_LEN bytes] + SERVER_PK Y [G_LEN bytes] + AUTH MAC(auth_input, t_hsmac) [H_LEN bytes] - These faileds can be send to the client in a RENDEZVOUS1 cell. - (See [JOIN_REND] below.) + These fields will be sent to the client in a RENDEZVOUS1 cell using the + HANDSHAKE_INFO element (see [JOIN_REND]). The hidden service host now also knows the keys generated by the handshake, which it will use to encrypt and authenticate data @@ -1578,7 +1576,7 @@ Status: Draft to authenticate. [TODO: should this be an identifier for the public key instead?] Signature is the signature, using Ed25519, of: - "Hidserv-userauth-ed25519" + "hidserv-userauth-ed25519" Nonce (same as above) Pubkey (same as above) AUTH_KEYID (As in the INTRODUCE1 cell) @@ -1653,6 +1651,8 @@ Status: Draft HANDSHAKE_INFO correctly completes a handshake, and uses the handshake output to derive shared keys for use on the circuit. + [TODO: How do we derive shared keys exactly? How do we use NTOR_KEY_SEED?] + [TODO: Should we encrypt HANDSHAKE_INFO as we did INTRODUCE2 contents? It's not necessary, but it could be wise. Similarly, we should make it extensible.]

1 0

[torspec/master] prop224: Add missing key expansion section for rendezvous crypto.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 65f186e80c6ee425c2e9cf479cdf6ca66c51a337 Author: George Kadianakis <desnacked(a)riseup.net> Date: Fri Mar 18 12:10:35 2016 +0200 prop224: Add missing key expansion section for rendezvous crypto. --- proposals/224-rend-spec-ng.txt | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index aee91bf..51d6ea4 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1144,7 +1144,7 @@ Status: Draft In this older protocol, an ESTABLISH_INTRO cell contains: - KEY_LEN [2 bytes] + KEY_LEN [2 bytes] KEY [KEY_LEN bytes] HANDSHAKE_AUTH [20 bytes] SIG [variable, up to end of relay payload] @@ -1649,10 +1649,39 @@ Status: Draft client containing the contents of the RENDEZVOUS1 cell. Upon receiving the RENDEZVOUS2 cell, the client verifies that the - HANDSHAKE_INFO correctly completes a handshake, and uses the - handshake output to derive shared keys for use on the circuit. + HANDSHAKE_INFO correctly completes a handshake. Now both parties use the + handshake output to derive shared keys for use on the circuit as specified + in the section below: - [TODO: How do we derive shared keys exactly? How do we use NTOR_KEY_SEED?] +4.2.1. Key expansion + + The hidden service and its client need to derive crypto keys from the + NTOR_KEY_SEED part of the handshake output. To do so, they use the key + expansion construction specified in prop216: + + K = K_1 | K_2 | K_3 | ... + + Where K_1 = MAC(NTOR_KEY_SEED, m_hsexpand | INT8(1)) + and K_(i+1) = MAC(NTOR_KEY_SEED, K_i | m_hsexpand | INT8(i)) + and INT8(i) is a octet with the value "i". + + + The key material is then used to generate KH, Df, Db, Kf, and Kb as in the + KDF-TOR key derivation approach documented in tor-spec.txt: + + The first HASH_LEN bytes of K form KH; the next HASH_LEN form the forward + digest Df; the next HASH_LEN 41-60 form the backward digest Db; the next + KEY_LEN 61-76 form Kf, and the final KEY_LEN form Kb. Excess bytes from K + are discarded. + + Subsequently, the rendezvous point passes relay cells, unchanged, from each + of the two circuits to the other. When Alice's OP sends RELAY cells along + the circuit, it authenticates with Df, and encrypts them with the Kf, then + with all of the keys for the ORs in Alice's side of the circuit; and when + Alice's OP receives RELAY cells from the circuit, it decrypts them with the + keys for the ORs in Alice's side of the circuit, then decrypts them with Kb, + and checks integrity with Db. Bob's OP does the same, with Kf and Kb + interchanged. [TODO: Should we encrypt HANDSHAKE_INFO as we did INTRODUCE2 contents? It's not necessary, but it could be wise. Similarly, we

1 0

[torspec/master] prop224: Clarify backwards compatibility sections slightly.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit dd7933d8158cefff2ecf0e325b21ac22aed49978 Author: George Kadianakis <desnacked(a)riseup.net> Date: Fri Apr 8 19:15:34 2016 +0300 prop224: Clarify backwards compatibility sections slightly. --- proposals/224-rend-spec-ng.txt | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 51d6ea4..b3a567c 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1151,7 +1151,8 @@ Status: Draft The KEY_LEN variable determines the length of the KEY field. - The KEY field is a ASN1-encoded RSA public key. + The KEY field is the ASN1-encoded legacy RSA public key that was also + included in the hidden service descriptor. The HANDSHAKE_AUTH field contains the SHA1 digest of (KH | "INTRODUCE"). @@ -1323,24 +1324,24 @@ Status: Draft 3.2.3. Legacy formats [LEGACY-INTRODUCE1] - When the ESTABLISH_INTRO cell format of [LEGACY_EST_INTRO] is used, - INTRODUCE1 cells are of the form: + If a hidden service has listed a legacy introduction point in its + descriptor, INTRODUCE1 cells should be of the form: - AUTH_KEYID_HASH [20 bytes] - ENC_KEYID [8 bytes] - - EXT_FIELD_TYPE [1 byte] - EXT_FIELD_LEN [1 byte] - EXT_FIELD [EXT_FIELD_LEN bytes] - - ENCRYPTED [Up to end of relay payload] + LEGACY_KEYID_HASH [20 bytes] + ENC_KEYID [8 bytes] + N_EXTENSIONS [1 byte] + N_EXTENSIONS times: + EXT_FIELD_TYPE [1 byte] + EXT_FIELD_LEN [1 byte] + EXT_FIELD [EXT_FIELD_LEN bytes] + ENCRYPTED [Up to end of relay payload] - Here, AUTH_KEYID_HASH is the hash of the introduction point - authentication key used to establish the introduction. + Here, LEGACY_KEYID_HASH is the hash of the introduction point legacy + encryption key that was included in the hidden service descriptor. - Because of limitations in older versions of Tor, the relay payload - size for these INTRODUCE1 cells must always be at least 246 bytes, or - they will be rejected as invalid. + Because of limitations in older versions of Tor, the relay payload size for + these INTRODUCE1 cells must always be at least 246 bytes, or they will be + rejected as invalid. [TODO: Do we need to pad with something?] 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2]

1 0

[torspec/master] prop224: Remove the MAINT_INTRO feature.
by asn＠torproject.org 09 Apr '16

09 Apr '16

commit 76b26c5dd46a633136e9d811125d91049b1b40a8 Author: George Kadianakis <desnacked(a)riseup.net> Date: Mon Apr 4 12:50:59 2016 +0300 prop224: Remove the MAINT_INTRO feature. Too complex and not sufficient gain. For full rationale, please see thread: https://lists.torproject.org/pipermail/tor-dev/2016-March/010560.html --- proposals/224-rend-spec-ng.txt | 79 +----------------------------------------- 1 file changed, 1 insertion(+), 78 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index b3a567c..833224b 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1088,11 +1088,6 @@ Status: Draft [00, 01] -- Reserved for legacy introduction cells; see [LEGACY_EST_INTRO below] [02] -- Ed25519; SHA3-256. - [FF] -- Reserved for maintenance messages on existing - circuits; see MAINT_INTRO below. - - [TODO: Should this just be a new relay cell type? - Matthew and George think so.] The AUTH_KEY_LEN field determines the length of the AUTH_KEY field. The AUTH_KEY field contains the public introduction point @@ -1163,71 +1158,6 @@ Status: Draft authentication keys. Newer hidden services MAY use RSA keys up 1904 bits. Any more than that will not fit in a RELAY cell payload. -3.1.3. Managing introduction circuits [MAINT_INTRO] - - If the first byte of an ESTABLISH_INTRO cell is [FF], the cell's body - contains an administrative command for the circuit. The format of - such a command is: - - Any number of times: - SUBCOMMAND_TYPE [2 bytes] - SUBCOMMAND_LEN [2 bytes] - SUBCOMMAND [COMMAND_LEN bytes] - - Recognized SUBCOMMAND_TYPE values are: - - [00 01] -- update encryption keys - - [TODO: Matthew says, "This can be used to fork an intro point to - balance traffic over multiple hidden service servers while - maintaining the criteria for a valid ESTABLISH_INTRO - cell. -MF". Investigate.] - - Unrecognized SUBCOMMAND_TYPE values should be ignored. - -3.1.3.1. Updating encryption keys (subcommand 0001) [UPDATE-KEYS-SUBCMD] - - Hidden service hosts send this subcommand to set their initial - encryption keys or update the configured public encryption keys - associated with this circuit. This message must be sent after - establishing an introduction point, before the circuit can be - advertised. These keys are given in the form: - - NUMKEYS [1 byte] - NUMKEYS times: - KEYTYPE [1 byte] - KEY [depends on KEYTYPE] - COUNTER [4 bytes] - SIGLEN [1 byte] - SIGNATURE [SIGLEN bytes.] - - The COUNTER field is a monotonically increasing value across a given - introduction point authentication key. - - The SIGNATURE must be generated with the introduction point - authentication key, and must cover the entire subcommand body, - prefixed with the string "Tor hidden service introduction encryption - keys v1". - - [TODO: Nothing is done here to prove ownership of the encryption - keys. Does that matter?] - - [TODO: The point here is to allow encryption keys to change while - maintaining an introduction point and not forcing a client to - download a new descriptor. I'm not sure if that's worth it. It makes - clients who have seen a key before distinguishable from ones who have - not.] - - [Matthew says: "Repeat-client over long periods of time will always - be distinguishable. It may be better to simply expire intro points - than try to preserve forward-secrecy, though". Must find out what he - meant.] - - Setting the encryption keys for a given circuit replaces the previous - keys for that circuit. Clients who attempt to connect using the old - key receive an INTRO_ACK cell with error code [00 02] as described in - section [INTRO_ACK] below. - 3.1.4. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] After setting up an introduction circuit, the introduction point reports its @@ -1301,6 +1231,7 @@ Status: Draft 3.2.2. INTRODUCE_ACK cell format. [INTRO_ACK] An INTRODUCE_ACK cell has the following fields: + STATUS [2 bytes] N_EXTENSIONS [1 bytes] N_EXTENSIONS times: @@ -1314,14 +1245,6 @@ Status: Draft [00 02] -- Failure: key ID not recognized [00 03] -- Bad message format - Recognized extension field types: - [00 01] -- signed set of encryption keys - - The extension field type 0001 is a signed set of encryption keys; its - body matches the body of the key update command in - [UPDATE-KEYS-CMD]. Whenever sending status [00 02], the introduction - point MUST send this extension field. - 3.2.3. Legacy formats [LEGACY-INTRODUCE1] If a hidden service has listed a legacy introduction point in its

1 0

[translation/tails-onioncircuits_completed] Update translations for tails-onioncircuits_completed
by translation＠torproject.org 09 Apr '16

09 Apr '16

commit 6303f63745ce28eccb7caa98c69c9c599abb82c9 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Apr 9 08:16:56 2016 +0000 Update translations for tails-onioncircuits_completed --- da/onioncircuits.pot | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) diff --git a/da/onioncircuits.pot b/da/onioncircuits.pot new file mode 100644 index 0000000..00878d5 --- /dev/null +++ b/da/onioncircuits.pot @@ -0,0 +1,92 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# +# Translators: +# Thomas Pryds <thomas(a)pryds.eu>, 2016 +msgid "" +msgstr "" +"Project-Id-Version: The Tor Project\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2016-03-31 21:31+0200\n" +"PO-Revision-Date: 2016-04-09 08:04+0000\n" +"Last-Translator: Thomas Pryds <thomas(a)pryds.eu>\n" +"Language-Team: Danish (http://www.transifex.com/otf/torproject/language/da/)\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Language: da\n" +"Plural-Forms: nplurals=2; plural=(n != 1);\n" + +#: ../onioncircuits:81 +msgid "" +"Cannot connect to the Tor daemon. Onion Circuits will try to reconnect..." +msgstr "Kan ikke forbinde til Tor-dæmonen. Onion Circuits vil prøve at genforbinde…" + +#: ../onioncircuits:94 +msgid "Onion Circuits" +msgstr "Onion Circuits" + +#: ../onioncircuits:95 +msgid "Display Tor circuits and streams" +msgstr "Vis Tor-kredsløb og -strømme" + +#: ../onioncircuits:107 +msgid "OK" +msgstr "OK" + +#: ../onioncircuits:124 +msgid "Path" +msgstr "Sti" + +#: ../onioncircuits:125 +msgid "Status" +msgstr "Status" + +#: ../onioncircuits:141 +msgid "Click on a path to get details" +msgstr "Klik på en sti for detaljer" + +#: ../onioncircuits:215 +msgid "" +"Lost connection to the Tor daemon. Onion Circuits will try to reconnect..." +msgstr "Mistede forbindelsen til Tor-dæmonen. Onion Circuits vil prøve at genforbinde…" + +#: ../onioncircuits:232 +msgid "Connected to the Tor daemon! You can use now Onion Circuits." +msgstr "Forbundet til Tor-dæmonen! Du kan nu bruge Onion Circuits." + +#: ../onioncircuits:314 +msgid "Building..." +msgstr "Opbygger…" + +#: ../onioncircuits:339 +#, c-format +msgid "%s: %s" +msgstr "%s: %s" + +#: ../onioncircuits:564 +msgid "Fingerprint:" +msgstr "Fingeraftryk:" + +#: ../onioncircuits:565 +msgid "Published:" +msgstr "Udgivet:" + +#: ../onioncircuits:566 +msgid "IP:" +msgstr "IP:" + +#: ../onioncircuits:566 +#, c-format +msgid "%s (%s)" +msgstr "%s (%s)" + +#: ../onioncircuits:567 +msgid "Bandwidth:" +msgstr "Båndbredde:" + +#: ../onioncircuits:567 +#, c-format +msgid "%.2f Mb/s" +msgstr "%.2f Mb/s"

1 0

[translation/tails-onioncircuits] Update translations for tails-onioncircuits
by translation＠torproject.org 09 Apr '16

09 Apr '16

commit 8f778bd4831c18e42ee8370b009b18ac3d2ad0c3 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Apr 9 08:16:52 2016 +0000 Update translations for tails-onioncircuits --- da/onioncircuits.pot | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/da/onioncircuits.pot b/da/onioncircuits.pot index 06560be..00878d5 100644 --- a/da/onioncircuits.pot +++ b/da/onioncircuits.pot @@ -3,13 +3,14 @@ # This file is distributed under the same license as the PACKAGE package. # # Translators: +# Thomas Pryds <thomas(a)pryds.eu>, 2016 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2016-03-26 00:31+0100\n" -"PO-Revision-Date: 2016-03-30 03:31+0000\n" -"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" +"POT-Creation-Date: 2016-03-31 21:31+0200\n" +"PO-Revision-Date: 2016-04-09 08:04+0000\n" +"Last-Translator: Thomas Pryds <thomas(a)pryds.eu>\n" "Language-Team: Danish (http://www.transifex.com/otf/torproject/language/da/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -20,15 +21,15 @@ msgstr "" #: ../onioncircuits:81 msgid "" "Cannot connect to the Tor daemon. Onion Circuits will try to reconnect..." -msgstr "" +msgstr "Kan ikke forbinde til Tor-dæmonen. Onion Circuits vil prøve at genforbinde…" #: ../onioncircuits:94 msgid "Onion Circuits" -msgstr "" +msgstr "Onion Circuits" #: ../onioncircuits:95 msgid "Display Tor circuits and streams" -msgstr "" +msgstr "Vis Tor-kredsløb og -strømme" #: ../onioncircuits:107 msgid "OK" @@ -44,25 +45,25 @@ msgstr "Status" #: ../onioncircuits:141 msgid "Click on a path to get details" -msgstr "" +msgstr "Klik på en sti for detaljer" #: ../onioncircuits:215 msgid "" "Lost connection to the Tor daemon. Onion Circuits will try to reconnect..." -msgstr "" +msgstr "Mistede forbindelsen til Tor-dæmonen. Onion Circuits vil prøve at genforbinde…" #: ../onioncircuits:232 msgid "Connected to the Tor daemon! You can use now Onion Circuits." -msgstr "" +msgstr "Forbundet til Tor-dæmonen! Du kan nu bruge Onion Circuits." #: ../onioncircuits:314 msgid "Building..." -msgstr "" +msgstr "Opbygger…" #: ../onioncircuits:339 #, c-format msgid "%s: %s" -msgstr "" +msgstr "%s: %s" #: ../onioncircuits:564 msgid "Fingerprint:" @@ -70,16 +71,16 @@ msgstr "Fingeraftryk:" #: ../onioncircuits:565 msgid "Published:" -msgstr "" +msgstr "Udgivet:" #: ../onioncircuits:566 msgid "IP:" -msgstr "" +msgstr "IP:" #: ../onioncircuits:566 #, c-format msgid "%s (%s)" -msgstr "" +msgstr "%s (%s)" #: ../onioncircuits:567 msgid "Bandwidth:" @@ -88,4 +89,4 @@ msgstr "Båndbredde:" #: ../onioncircuits:567 #, c-format msgid "%.2f Mb/s" -msgstr "" +msgstr "%.2f Mb/s"

1 0

[translation/tor-messenger-ircproperties_completed] Update translations for tor-messenger-ircproperties_completed
by translation＠torproject.org 09 Apr '16

09 Apr '16

commit ec1266cc9ce935243e161f5a61ec45edeacbdbb1 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Apr 9 08:16:32 2016 +0000 Update translations for tor-messenger-ircproperties_completed --- da/irc.properties | 3 +++ 1 file changed, 3 insertions(+) diff --git a/da/irc.properties b/da/irc.properties index 8fee831..6cc4762 100644 --- a/da/irc.properties +++ b/da/irc.properties @@ -172,6 +172,9 @@ error.sendMessageFailed=Der skete en fejl, da sidste besked blev afsendt. Prøv # %1$S is the channel the user tried to join, %2$S is the channel # he was forwarded to. error.channelForward=Du har ikke tilladelse til at gå ind i %1$S og blev automatisk videre dirigeret til %2$S. +# %S is the mode that the user tried to set but was not recognized +# by the server as a valid mode. +error.unknownMode="%S" er ikke en gyldig brugertilstand på denne server. # LOCALIZATION NOTE (tooltip.*): # These are the descriptions given in a tooltip with information received

1 0

[translation/tor-messenger-ircproperties] Update translations for tor-messenger-ircproperties
by translation＠torproject.org 09 Apr '16

09 Apr '16

commit 55298687c59c1bf04f4cd2a82df3e6f1d80d213b Author: Translation commit bot <translation(a)torproject.org> Date: Sat Apr 9 08:16:28 2016 +0000 Update translations for tor-messenger-ircproperties --- da/irc.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/da/irc.properties b/da/irc.properties index b0e60c1..6cc4762 100644 --- a/da/irc.properties +++ b/da/irc.properties @@ -174,7 +174,7 @@ error.sendMessageFailed=Der skete en fejl, da sidste besked blev afsendt. Prøv error.channelForward=Du har ikke tilladelse til at gå ind i %1$S og blev automatisk videre dirigeret til %2$S. # %S is the mode that the user tried to set but was not recognized # by the server as a valid mode. -error.unknownMode='%S' is not a valid user mode on this server. +error.unknownMode="%S" er ikke en gyldig brugertilstand på denne server. # LOCALIZATION NOTE (tooltip.*): # These are the descriptions given in a tooltip with information received

1 0

[tor-browser-spec/master] Commit partial progress FF45 audit doc.
by mikeperry＠torproject.org 08 Apr '16

08 Apr '16

commit f66c31f82b04376a31cd564b250a1ee6bb2cac0b Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Mon Mar 21 10:49:26 2016 -0700 Commit partial progress FF45 audit doc. Still XPCOM remains, but that is relatively lower risk. --- audits/FF45_NETWORK_AUDIT | 412 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 412 insertions(+) diff --git a/audits/FF45_NETWORK_AUDIT b/audits/FF45_NETWORK_AUDIT new file mode 100644 index 0000000..2d749a8 --- /dev/null +++ b/audits/FF45_NETWORK_AUDIT @@ -0,0 +1,412 @@ +Lowest level resolver calls: + + PR_GetHostByName + + ./netwerk/protocol/rtsp/rtsp/RTSPConnectionHandler.h + - MOZ_RTSP -> Only on android. XXX: Verify disabled + + ./netwerk/protocol/rtsp/rtsp/ARTSPConnection.cpp + - MOZ_RTSP -> Only on android. XXX: Verify disabled + + ./security/nss/lib/certhigh/ocsp.c: + - Patched (XXX: Verify application) + + ./security/nss/lib/libpkix/pkix_pl_nss/module/pkix_pl_socket.c + + pkix_pl_Socket_CreateByName() + - Patched (XXX: Verify application) + + pkix_pl_Socket_CreateByHostAndPort() + - Patched (XXX: Verify application) + + ./security/nss/cmd/ + + NSS cli commands only + + ./nsprpub/pr/src/misc/prnetdb.c + + Fallback for PR_GetAddrInfoByName + + ./nsprpub/pr/src/cplus/rcnetdb.cpp + + RCHostLookup::ByName() + + Still Not used + - ./toolkit/profile/nsProfileLock.cpp + - nsProfileLock::LockWithSymlink() looks up 127.0.0.1.. + - XXX: We should patch this. + + PR_GetIPNodeByName + + Used by tests only + + PR_StringToNetAddr + + Passes AI_NUMERICHOST to getaddrinfo. No resolution. + + + PR_GetAddrInfoByName + + ./security/nss/cmd/ usage (NSS cli commands only) + - ./netwerk/dns/mdns/libmdns/* + - XXX: New. Possibly android only? + + ./netwerk/dns/GetAddrInfo.cpp + + ./netwerk/dns/nsHostResolver.cpp + - nsHostResolver::ResolveHost() is entrypoint + + nsHostResolver::ThreadFunc() will resolve without SOCKS + + Only used by nsDNSService2 + - XXX: Watch out for the new parent/child interfaces.. + +MDNS: (./netwerk/dns/mdns/libmdns/) XXX + - @mozilla.org/toolkit/components/mdnsresponder/dns-sd;1 + - DNSSERVICEDISCOVERY_CONTRACT_ID + - ./dom/presentation/provider/MulticastDNSDeviceProvider.cpp + - XXX: Presentation API? + https://developer.mozilla.org/en-US/docs/Web/API/Presentation_API + - DNSSERVICEINFO_CONTRACT_ID + - ./dom/presentation/provider/MulticastDNSDeviceProvider.cpp + - @mozilla.org/toolkit/components/mdnsresponder/dns-info;1 + +Direct paths to DNS resolution: + + nsHostResolver::ResolveHost + + Only used by nsDNSService + + nsDNSService::Resolve + - Patched for safety (XXX: Verify application) + + nsDNSService::AsyncResolve + - Patched for safety (XXX: Verify application) + - ChildDNSService::AsyncResolve and ChildDNSService::Resolve + - Possibly only active if MOZILLA_XPCOMRT_API is defined.. But it seems to + be. + - ./netwerk/dns/ChildDNSService.cpp + - XXX: Should patch AsyncResolve and Resolve here, as we do in + nsDNSService. + - XXX: New parent/child interfaces DNSRequestParent and DNSRequestChild + + ./netwerk/ipc/NeckoParent.cpp + + Calls into DNS service via DNSRequestParent::DoAsyncResolve() + + ./netwerk/ipc/NeckoChild.cpp + +Misc UDP (SOCK_DGRAM, PR_DESC_SOCKET_UDP): + + PR_DESC_SOCKET_UDP + + ./nsprpub/pr/src/cplus/rcio.h + + RCIO (not used) + + RCFileIO (not used) + + RCNetStreamIO (not used) + + ./nsprpub/pr/src/io/prsocket.c + + PR_GetUDPMethods + + ./nsprpub/pr/src/md/os2/os2io.c + + ./nsprpub/pr/src/misc/prinit.c + + PR_GetInheritedFD + + ./nsprpub/pr/src/pthreads/ptio.c + + Reviewed below + + SOCK_DGRAM + - Android: XXX: Are these patched in Orfox? + - ./other-licenses/android/res_send.c + - ./other-licenses/android/res_init.c + - ./other-licenses/android/getaddrinfo.c + + ./hal/gonk/UeventPoller.cpp + + netlink stuff + + ./ipc/chromium/src/third_party/libevent/evdns.c + + evdns is unused + + ./ipc/chromium/src/third_party/libevent/evutil.c + + interface checking functions. Unused. + + ./media/webrtc/* + + Can be disabled still + + ./media/mtransport/third_party/nICEr/src/stun/addrs.c + + boils down to NrIceCtx::StartGathering + + Used only for PeerConnection, which we disable + + SCTP is only enabled with WEBRTC (see configure.in, netwerk/moz.build, and ./dom/base/moz.build) + + ./netwerk/sctp/src/netinet/sctputil.c + + ./netwerk/sctp/src/netinet/sctp_userspace.c + + ./netwerk/sctp/src/netinet/sctp_pcb.c + + ./netwerk/sctp/src/ifaddrs_android.cpp + + ./netwerk/sctp/src/user_recv_thread.c + + ./netwerk/wifi/nsWifiScannerFreeBSD.cpp + + GeoIP stuff. Is disabled. + + ./nsprpub/pr/src/io/prsocket.c + + PR_NewUDPSocket + + PR_OpenUDPSocket + + PR_Socket + + ./nsprpub/pr/src/pthreads/ptio.c + + PR_NewUDPSocket + + PR_OpenUDPSocket + + ./media/mtransport/nr_socket_prsock.cpp + + Disabled with WebRTC + + ./netwerk/base/src/nsUDPSocket.cpp + + Unused except for nsUDPSocketProvider + + RTSP is only on Android (see configure.in, pref: media.rtsp.enabled): + + ./netwerk/protocol/rtsp/rtsp/ARTPSession.cpp + + ./netwerk/protocol/rtsp/rtsp/ARTPConnection.cpp + + ./netwerk/protocol/rtsp/rtsp/ARTPWriter.cpp + + ./netwerk/protocol/rtsp/rtsp/UDPPusher.cpp + - ./netwerk/base/src/Tickler.cpp + - XXX: Sends a UDP packet to the gateway. Possibly governed by + network.predictor.enabled, but called from many places. + - XXX: A direct patch to nsHttpHandler::TickleWifi() or + the tickler itself may be a good idea + + ./netwerk/socket/nsUDPSocketProvider.cpp + + NewSocket(). Unused. + + ./netwerk/base/src/ProxyAutoConfig.cpp + + We don't use PAC. + + PR_ImportUDPSocket + + Only called if NSPR_INHERIT_FDS in environment + + Also only inherits existing UDP sockets + +Misc TCP (SOCK_STREAM, PR_DESC_SOCKET_TCP): + + PR_DESC_SOCKET_TCP + + ./netwerk/base/ClosingService.cpp + + Shutdown cleanup only + + ./netwerk/base/nsSocketTransportService2.cpp + + ./nsprpub/pr/src/cplus/rcio.h + + RCFileIO (not used) + + RCNetStreamIO (not used) + + ./nsprpub/pr/src/io/pripv6.c + + Underlying wrapper for PR_Socket + + ./nsprpub/pr/src/md/os2/os2io.c + + OS/2 only + + ./nsprpub/pr/src/io/prsocket.c + + ./nsprpub/pr/src/misc/prinit.c + + ./nsprpub/pr/src/pthreads/ptio.c + + SOCK_STREAM + + ./dom/bluetooth/bluez/BluetoothUnixSocketConnector.cpp + + bluetooth sockets only for B2G + + ./dom/system/gonk/VolumeManager.cpp + + local only + + Android stuff: disabled. XXX: Verify on OrFox + + ./other-licenses/android/res_send.c + + ./other-licenses/android/getaddrinfo.c + + ./mozglue/build/Nuwa.cpp + + ./netwerk/sctp/ + + Disabled with WebRTC + + ./netwerk/dns/GetAddrInfo.cpp + + Only available through dns service and mdns + + ./ipc/chromium/src/third_party/libevent/event.c + + ./ipc/chromium/src/third_party/libevent/evutil.c + + ./ipc/chromium/src/third_party/libevent/listener.c + + ./ipc/chromium/src/third_party/libevent/bufferevent_sock.c + + ./ipc/chromium/src/third_party/libevent/signal.c + + ./ipc/chromium/src/third_party/libevent/http.c + + ./ipc/chromium/src/third_party/libevent/event_iocp.c + + ./ipc/keystore/KeyStore.cpp + + AF_LOCAL only + + ./ipc/nfc/Nfc.cpp + + local/loopback only + + ./ipc/ril/Ril.cpp + + local/loopback only + + ./ipc/netd/Netd.cpp + + local only + + ./ipc/chromium/src/chrome/common/ipc_channel_posix.cc + + AF_UNIX/local only + + ./nsprpub/pr/src/misc/prnetdb.c + + ./media/webrtc/* - disabled + + ./mozglue/build/Nuwa.cpp + + Unix sockets only + + RTSP and SCTP are disabled if WebRTC is compiled out + + ./netwerk/protocol/rtsp/rtsp/ARTSPConnection.cpp + + ./netwerk/sctp/src/netinet/sctp_pcb.c + + ./netwerk/sctp/src/user_socket.c + + ./netwerk/sctp/datachannel/DataChannel.cpp + + ./nsprpub/pr/src/md/windows/ntio.c + + ./nsprpub/pr/src/cplus/rcnetio.cpp + + ./nsprpub/pr/src/io/prsocket.c + + ./nsprpub/pr/src/misc/prnetdb.c + + ./nsprpub/pr/src/pthreads/ptio.c + + ./toolkit/crashreporter/google-breakpad/src/client/linux/crash_generation/crash_generation_client.cc + + AF_UNIX socket.. + + PR_NewTCPSocket + + ./security/nss/lib/certhigh/ocsp.c + + ocsp_ConnectToHost. Patched for Defense in Depth + - XXX: Verify patch after rebase. + + ./security/nss/lib/libpkix/pkix_pl_nss/module/pkix_pl_socket.c + + pkix_pl_Socket_CreateClient + + pkix_pl_Socket_CreateByHostAndPort and pkix_pl_Socket_CreateByName + and pkix_pl_Socket_Create + + PKIX_PL_LdapDefaultClient_Create is unused. Other two noted above. + + Patched in pkix_pl_Socket_Create anyway. + - XXX: Verify patch + + ./nsprpub/pr/src/cplus/rcnetio.cpp + + ./nsprpub/pr/src/io/prpolevt.c + + ./media/mtransport/nr_socket_prsock.cpp + + WebRTC only + + + PR_OpenTCPSocket + + ./netwerk/base/src/nsSocketTransport2.cpp + + ./netwerk/base/src/nsServerSocket.cpp + + ./netwerk/protocol/rtsp/rtsp/ARTSPConnection.cpp + + ./netwerk/socket/nsSOCKSIOLayer.cpp + + ./netwerk/socket/nsSOCKSSocketProvider.cpp + + ./netwerk/base/src/nsSocketTransportService2.cpp + + ./security/manager/ssl/src/nsNSSIOLayer.cpp + + nsSSLIOLayerNewSocket + + ./security/manager/ssl/src/nsTLSSocketProvider.cpp + + nsTLSSocketProvider::NewSocket + + ./security/manager/ssl/src/nsSSLSocketProvider.cpp + + nsSSLSocketProvider::NewSocket (nsISocketProvider) + + nsISocketProvider.newSocket + + used with proxy settings (and only in nsSocketTransport::BuildSocket) + + PR_ImportTCPSocket + +Misc PR_Socket: + + ./nsprpub/pr/src/io/prmapopt.c + + ./nsprpub/pr/src/cplus/rcnetio.cpp + + RCNetStreamIO::RCNetStreamIO + + +Misc Wrappers: + - UDPSocketChild: + + ./dom/push/PushServiceWebSocket.jsm + - XXX: Should be disabled by ServiceWorkers, but we should also + disable the dom.push.* prefs, as well, to remind us if/when + we enable service workers. + + ./netwerk/ipc/NeckoChild.cpp + + E10S stuff. Not relevant in ESR45. + + ./netwerk/ipc/NeckoParent.cpp + + E10S stuff. Not relevant in ESR45. + + /ipc/glue/Background* + + E10S gunk. Not relevant in ESR45. + - ./toolkit/modules/secondscreen/SimpleServiceDiscovery.jsm + - XXX: Bad news. seems included. + - UDPSocket + - ./dom/simplepush/PushService.jsm + - Should be FxOS only and disabled. + - ./dom/media/bridge/MediaModule.cpp + - Dependent on WebRTC. Should be disabled + - ./dom/webidl/UDPMessageEvent.webidl + - XXX: dom.udpsocket.enabled verify. + + ./dom/webidl/UDPSocket.webidl + + dom.udpsocket.enabled + - ./devtools/shared/discovery/discovery.js + - XXX: Did we disable this? I vaguely remember a ticket about the debugger.. + - TCPSocket + - ./dom/base/Navigator.cpp + - XXX: Controlled by pref dom.mozTCPSocket.enabled + + ./dom/network/TCPSocket.h and friends + + also dom.mozTCPSocket.enabled. + + ./netwerk/protocol/rtsp/rtsp/* + + Disabled + - ./browser/extensions/shumway/content/shumway.player.js + - XXX: Boo. Shumway tells people to flip the mozTCPSocket pref? + + webrtc and mtransport again, but disabled. + + +Misc XPCOM: + + *SocketProvider + + newSocket + + ./netwerk/base/src/nsSocketTransport2.cpp: + + used with proxy settings + + addToSocket + + @mozilla.org/*/udp-socket (grep -R udp-socket .) + + dom/push/PushService.jsm: + + WTF. _listenForUDPWakeup!!! + + Controlled by pref services.push.udp.wakeupEnabled + + And also services.push.enabled + + Currently false + - XXX: Verify false on android and in the future! + + ./dom/push/PushServiceWebSocket.jsm + + dom/network/UDPSocket.cpp: + + dom.udpsocket.enabled prefs this off + - XXX: Watch this in the future! + + dom/apps/PermissionsTable.jsm + + dom/webidl/SocketCommon.webidl + + dom/webidl/UDPSocket.webidl + + layout/build/nsLayoutModule.cpp + + ./netwerk/build/nsNetCID.h + - toolkit/devtools/discovery/discovery.js + - XXX: Wtf is this thing? Vaguely remember disabling it? + - Part of "WebIDE", but seemingly not enabled until FF39? + - toolkit/modules/secondscreen/SimpleServiceDiscovery.jsm + - XXX: wtf is this thing? + + @mozilla.org/*/tcp-socket-* (grep for tcp-socket) + + ./netwerk/protocol/rtsp/ (disabled) + - ./dom/network/TCPSocket.js + - XXX: possibly exposed via navigator.mozTCPSocket.. dom.mozTCPSocket.enabled pref control.. Android/FxOS only? + - https://developer.mozilla.org/en-US/docs/Web/API/Navigator/mozTCPSocket + + ./dom/network/TCPSocket.manifest + + ./dom/apps/tests/marketplace/marketplace_privileged_app.webapp + + ./dom/apps/PermissionsTable.jsm + - ./browser/extensions/shumway/chrome/RtmpUtils.jsm + - XXX: Shumway currently only enabled in nightly builds, but keep an eye + on this.. + - XXX: shumway.rtmp.enabled governs usage of createSocket + + ./browser/extensions/shumway/chrome/viewerWrapper.js + + ./browser/extensions/shumway/chrome/content.js + + ./browser/extensions/shumway/content/shumway.player.js can also use + mozTCPSocket + + ./layout/build/nsLayoutModule.cpp + + - @mozilla.org/network/*socket* (grep -R "@mozilla.org/network/" . | grep socket | grep -v udp-socket) + - ./dom/presentation/provider/TCPPresentationServer.js + - ./dom/ipc/preload.js + - ./netwerk/protocol/websocket/WebSocketChannel.cpp + - ./devtools/shared/security/socket.js + - ./mobile/android/chrome/content/WebappRT.js + - ./browser/extensions/loop/chrome/content/modules/MozLoopPushHandler.jsm + - ./toolkit/modules/Sntp.jsm + - ./toolkit/modules/secondscreen/RokuApp.jsm + - ./toolkit/xre/nsAppRunner.cpp + + + ./addon-sdk/source/lib/sdk/io/stream.js + + Addon APIs + + ./dom/ipc/preload.js + + ./dom/network/TCPServerSocket.js + - ./mobile/android/chrome/content/WebappRT.js + - Debugger? + - XXX: Pretty sure this is only for 'webapps', but it sets some scary + prefs that might impact other browser operation if an app is + installed? + + ./netwerk/build/nsNetCID.h + - Debugger stuff + - XXX: Has several prefs: + - devtools.webide.enabled + - devtools.debugger.enabled? + - devtools.debugger.remote-enabled + - devtools.debugger.force-local + - devtools.remote.tls-handshake-timeout + - ./toolkit/devtools/server/main.js + - ./toolkit/devtools/client/connection-manager.js + - ./toolkit/devtools/client/dbg-client.jsm + - ./toolkit/devtools/security/socket.js + - ./toolkit/modules/Sntp.jsm + - B2G ntp + - ./toolkit/xre/nsAppRunner.cpp + + createTransport() + - ./netwerk/base/Dashboard.cpp + -XXX: What the hell is this? + + Found earlier: + + ./toolkit/devtools/security/socket.js: + + ./toolkit/modules/Sntp.jsm: + + ./toolkit/modules/secondscreen/RokuApp.jsm + + ./netwerk/protocol/http/nsHttpConnectionMgr.cpp + + ./netwerk/protocol/ftp/nsFtpConnectionThread.cpp + + ./netwerk/protocol/ftp/nsFtpControlConnection.cpp + +- Misc XPCOM Contract-ID/CID defines: + - NS_*SOCKET*_C should get them all (grep -R "NS_" | grep SOCKET | grep "_C") + + WebRTC and mtransport (disabled) + - gfx/layers/LayerScope.cpp + - XXX + + + NS_SOCKETTRANSPORTSERVICE_* + + Proxied if TCP + + Udp limited to mtransport and webrtc + + NS_UDPSOCKET_* + + + netwerk/protocol/websocket/WebSocketChannel.cpp: + + netwerk/protocol/http/nsHttpHandler.cpp: + + netwerk/protocol/http/nsHttpConnectionMgr.cpp: + + netwerk/protocol/http/TunnelUtils.cpp: + + netwerk/protocol/ftp/nsFtpConnectionThread.cpp: + + netwerk/protocol/ftp/nsFtpControlConnection.cpp + + netwerk/base/nsIOService.cpp: + + dom/media/bridge/MediaModule.cpp + + Compiled out by webrtc + + dom/workers/ServiceWorkerEvents.cpp: + + dom/bluetooth2/bluedroid/BluetoothDaemonInterface.cpp + + b2g only + + security/manager/ssl/src/SSLServerCertVerification.cpp: + + security/manager/ssl/src/nsNSSCallbacks.cpp: + + security/manager/ssl/src/nsNSSModule.cpp: + + security/manager/ssl/src/nsTLSSocketProvider.cpp: + + security/manager/ssl/src/SharedSSLState.cpp: + + ++ Gstreamer + + ./dom/media/gstreamer/GStreamerDecoder.cpp + + Uses ChannelMediaResource underneath, and ultimately an nsIChannel + + Only exception seems to be if an RtspMediaResource could be used, + but this appears to be FxOS-only. + + XXX: Note for FxOS tor support. This may be an issue. + +Android Java calls: + + Uses HttpURLConnection: + + mobile/android/base/CrashReporter.java + + mobile/android/base/SuggestClient.java + + mobile/android/base/distribution/Distribution.java + + Uses org.apache.http.client.* + + mobile/android/base/favicons/LoadFaviconTask.java + + Uses ch.boye.httpclientandroidlib.impl.client.*: + + mobile/android/base/sync/net/BaseResource.java + + mobile/android/base/CrashReporter.java + + mobile/android/base/SuggestClient.java + + mobile/android/base/distribution/Distribution.java + + mobile/android/search/java/org/mozilla/search/providers/SearchEngineManager.java + + mobile/android/stumbler/java/org/mozilla/mozstumbler/service/utils/AbstractCommunicator.java

1 0