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

[tor/release-0.4.5] Merge branch 'maint-0.4.5' into release-0.4.5
by nickm＠torproject.org 13 Apr '21

13 Apr '21

commit 1aa8fd66be0c1db3339b6b1fd6653981da9fbd75 Merge: 41ad333c2f 218f9f90fb Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 13 09:40:02 2021 -0400 Merge branch 'maint-0.4.5' into release-0.4.5 changes/ticket40360 | 5 +++++ src/feature/client/entrynodes.c | 3 --- 2 files changed, 5 insertions(+), 3 deletions(-)

1 0

[tor/release-0.4.5] guard: Don't check bridge transport name when selecting eligible guards
by nickm＠torproject.org 13 Apr '21

13 Apr '21

commit 218f9f90fb58ee521296fdc3b00189c70e4e4297 Author: David Goulet <dgoulet(a)torproject.org> Date: Thu Apr 8 14:08:28 2021 -0400 guard: Don't check bridge transport name when selecting eligible guards This is related to ticket #40360 which found this problem when a Bridge entry with a transport name (let say obfs4) is set without a fingerprint: Bridge obfs4 <IP>:<PORT> cert=<...> iat-mode=0 (Notice, no fingerprint between PORT and "cert=") Problem: commit 09c6d0324626ffa349c7eed66d9ede92ecd71583 added a check in get_sampled_guard_for_bridge() that would return NULL if the selected bridge did not have a valid transport name (that is the Bridge transport name that corresponds to a ClientTransportPlugin). Unfortuantely, this function is also used when selecting our eligible guards which is done *before* the transport list is populated and so the added check for the bridge<->transport name is querying an empty list of transports resulting in always returning NULL. For completion, the logic is: Pick eligible guards (use bridge(s) if need be) then for those, initiate a connection to the pluggable transport proxy and then populate the transport list once we've connected. Back to get_sampled_guard_for_bridge(). As said earlier, it is used when selecting our eligible guards in a way that prevents us from selecting duplicates. In other words, if that function returns non-NULL, the selection continues considering the bridge was sampled before. But if it returns NULL, the relay is added to the eligible list. This bug made it that our eligible guard list was populated with the *same* bridge 3 times like so (remember no fingerprint): [info] entry_guards_update_primary(): Primary entry guards have changed. New primary guard list is: [info] entry_guards_update_primary(): 1/3: [bridge] ($0000000000000000000000000000000000000000) [info] entry_guards_update_primary(): 2/3: [bridge] ($0000000000000000000000000000000000000000) [info] entry_guards_update_primary(): 3/3: [bridge] ($0000000000000000000000000000000000000000) When tor starts, it will find the bridge fingerprint by connecting to it and will then update the primary guard list by calling entry_guard_learned_bridge_identity() which then goes and update only 1 single entry resulting in this list: [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($<FINGERPRINT>) is still listed. [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed. [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed. And here lies the problem, now tor is stuck attempting to wait for a valid descriptor for at least 2 guards where the second one is a bunch of zeroes and thus tor will never fully bootstraps: [info] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6671/6703). That's ok. We will try to fetch missing descriptors soon. Now, why passing the fingerprint then works? This is because the list of guards contains 3 times the same bridge but they all have a fingerprint and so the descriptor can be found and tor can bootstraps. The solution here is to entirely remove the transport name check in get_sampled_guard_for_bridge() since the transport_list is empty at that point. That way, the eligible guard list only gets 1 entry, the bridge, and can then go on to bootstrap properly. It is OK to do so since when launching a bridge descriptor fetch, we validate that the bridge transport name is OK and thus avoid connecting to a bridge without a ClientTransportPlugin. If we wanted to keep the check in place, we would need to populate the transport_list much earlier and this would require a much bigger refactoring. Fixes #40360 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/ticket40360 | 5 +++++ src/feature/client/entrynodes.c | 3 --- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/changes/ticket40360 b/changes/ticket40360 new file mode 100644 index 0000000000..4a1b2c3446 --- /dev/null +++ b/changes/ticket40360 @@ -0,0 +1,5 @@ + o Minor bugfixes (bridge, pluggable transport): + - Fix a regression that prevented to configure a Bridge line without a + fingerprint (which is a normal use case). Fixes bug 40360; bugfix on + 0.4.5.4-rc. + diff --git a/src/feature/client/entrynodes.c b/src/feature/client/entrynodes.c index 232216c521..82866ea668 100644 --- a/src/feature/client/entrynodes.c +++ b/src/feature/client/entrynodes.c @@ -804,9 +804,6 @@ get_sampled_guard_for_bridge(guard_selection_t *gs, entry_guard_t *guard; if (BUG(!addrport)) return NULL; // LCOV_EXCL_LINE - if (bridge_has_invalid_transport(bridge)) { - return NULL; - } guard = get_sampled_guard_by_bridge_addr(gs, addrport); if (! guard || (id && tor_memneq(id, guard->identity, DIGEST_LEN))) return NULL;

1 0

[tor/master] guard: Don't check bridge transport name when selecting eligible guards
by nickm＠torproject.org 13 Apr '21

13 Apr '21

commit 218f9f90fb58ee521296fdc3b00189c70e4e4297 Author: David Goulet <dgoulet(a)torproject.org> Date: Thu Apr 8 14:08:28 2021 -0400 guard: Don't check bridge transport name when selecting eligible guards This is related to ticket #40360 which found this problem when a Bridge entry with a transport name (let say obfs4) is set without a fingerprint: Bridge obfs4 <IP>:<PORT> cert=<...> iat-mode=0 (Notice, no fingerprint between PORT and "cert=") Problem: commit 09c6d0324626ffa349c7eed66d9ede92ecd71583 added a check in get_sampled_guard_for_bridge() that would return NULL if the selected bridge did not have a valid transport name (that is the Bridge transport name that corresponds to a ClientTransportPlugin). Unfortuantely, this function is also used when selecting our eligible guards which is done *before* the transport list is populated and so the added check for the bridge<->transport name is querying an empty list of transports resulting in always returning NULL. For completion, the logic is: Pick eligible guards (use bridge(s) if need be) then for those, initiate a connection to the pluggable transport proxy and then populate the transport list once we've connected. Back to get_sampled_guard_for_bridge(). As said earlier, it is used when selecting our eligible guards in a way that prevents us from selecting duplicates. In other words, if that function returns non-NULL, the selection continues considering the bridge was sampled before. But if it returns NULL, the relay is added to the eligible list. This bug made it that our eligible guard list was populated with the *same* bridge 3 times like so (remember no fingerprint): [info] entry_guards_update_primary(): Primary entry guards have changed. New primary guard list is: [info] entry_guards_update_primary(): 1/3: [bridge] ($0000000000000000000000000000000000000000) [info] entry_guards_update_primary(): 2/3: [bridge] ($0000000000000000000000000000000000000000) [info] entry_guards_update_primary(): 3/3: [bridge] ($0000000000000000000000000000000000000000) When tor starts, it will find the bridge fingerprint by connecting to it and will then update the primary guard list by calling entry_guard_learned_bridge_identity() which then goes and update only 1 single entry resulting in this list: [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($<FINGERPRINT>) is still listed. [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed. [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed. And here lies the problem, now tor is stuck attempting to wait for a valid descriptor for at least 2 guards where the second one is a bunch of zeroes and thus tor will never fully bootstraps: [info] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6671/6703). That's ok. We will try to fetch missing descriptors soon. Now, why passing the fingerprint then works? This is because the list of guards contains 3 times the same bridge but they all have a fingerprint and so the descriptor can be found and tor can bootstraps. The solution here is to entirely remove the transport name check in get_sampled_guard_for_bridge() since the transport_list is empty at that point. That way, the eligible guard list only gets 1 entry, the bridge, and can then go on to bootstrap properly. It is OK to do so since when launching a bridge descriptor fetch, we validate that the bridge transport name is OK and thus avoid connecting to a bridge without a ClientTransportPlugin. If we wanted to keep the check in place, we would need to populate the transport_list much earlier and this would require a much bigger refactoring. Fixes #40360 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/ticket40360 | 5 +++++ src/feature/client/entrynodes.c | 3 --- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/changes/ticket40360 b/changes/ticket40360 new file mode 100644 index 0000000000..4a1b2c3446 --- /dev/null +++ b/changes/ticket40360 @@ -0,0 +1,5 @@ + o Minor bugfixes (bridge, pluggable transport): + - Fix a regression that prevented to configure a Bridge line without a + fingerprint (which is a normal use case). Fixes bug 40360; bugfix on + 0.4.5.4-rc. + diff --git a/src/feature/client/entrynodes.c b/src/feature/client/entrynodes.c index 232216c521..82866ea668 100644 --- a/src/feature/client/entrynodes.c +++ b/src/feature/client/entrynodes.c @@ -804,9 +804,6 @@ get_sampled_guard_for_bridge(guard_selection_t *gs, entry_guard_t *guard; if (BUG(!addrport)) return NULL; // LCOV_EXCL_LINE - if (bridge_has_invalid_transport(bridge)) { - return NULL; - } guard = get_sampled_guard_by_bridge_addr(gs, addrport); if (! guard || (id && tor_memneq(id, guard->identity, DIGEST_LEN))) return NULL;

1 0

[tor/maint-0.4.5] guard: Don't check bridge transport name when selecting eligible guards
by nickm＠torproject.org 13 Apr '21

13 Apr '21

commit 218f9f90fb58ee521296fdc3b00189c70e4e4297 Author: David Goulet <dgoulet(a)torproject.org> Date: Thu Apr 8 14:08:28 2021 -0400 guard: Don't check bridge transport name when selecting eligible guards This is related to ticket #40360 which found this problem when a Bridge entry with a transport name (let say obfs4) is set without a fingerprint: Bridge obfs4 <IP>:<PORT> cert=<...> iat-mode=0 (Notice, no fingerprint between PORT and "cert=") Problem: commit 09c6d0324626ffa349c7eed66d9ede92ecd71583 added a check in get_sampled_guard_for_bridge() that would return NULL if the selected bridge did not have a valid transport name (that is the Bridge transport name that corresponds to a ClientTransportPlugin). Unfortuantely, this function is also used when selecting our eligible guards which is done *before* the transport list is populated and so the added check for the bridge<->transport name is querying an empty list of transports resulting in always returning NULL. For completion, the logic is: Pick eligible guards (use bridge(s) if need be) then for those, initiate a connection to the pluggable transport proxy and then populate the transport list once we've connected. Back to get_sampled_guard_for_bridge(). As said earlier, it is used when selecting our eligible guards in a way that prevents us from selecting duplicates. In other words, if that function returns non-NULL, the selection continues considering the bridge was sampled before. But if it returns NULL, the relay is added to the eligible list. This bug made it that our eligible guard list was populated with the *same* bridge 3 times like so (remember no fingerprint): [info] entry_guards_update_primary(): Primary entry guards have changed. New primary guard list is: [info] entry_guards_update_primary(): 1/3: [bridge] ($0000000000000000000000000000000000000000) [info] entry_guards_update_primary(): 2/3: [bridge] ($0000000000000000000000000000000000000000) [info] entry_guards_update_primary(): 3/3: [bridge] ($0000000000000000000000000000000000000000) When tor starts, it will find the bridge fingerprint by connecting to it and will then update the primary guard list by calling entry_guard_learned_bridge_identity() which then goes and update only 1 single entry resulting in this list: [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($<FINGERPRINT>) is still listed. [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed. [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed. And here lies the problem, now tor is stuck attempting to wait for a valid descriptor for at least 2 guards where the second one is a bunch of zeroes and thus tor will never fully bootstraps: [info] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6671/6703). That's ok. We will try to fetch missing descriptors soon. Now, why passing the fingerprint then works? This is because the list of guards contains 3 times the same bridge but they all have a fingerprint and so the descriptor can be found and tor can bootstraps. The solution here is to entirely remove the transport name check in get_sampled_guard_for_bridge() since the transport_list is empty at that point. That way, the eligible guard list only gets 1 entry, the bridge, and can then go on to bootstrap properly. It is OK to do so since when launching a bridge descriptor fetch, we validate that the bridge transport name is OK and thus avoid connecting to a bridge without a ClientTransportPlugin. If we wanted to keep the check in place, we would need to populate the transport_list much earlier and this would require a much bigger refactoring. Fixes #40360 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/ticket40360 | 5 +++++ src/feature/client/entrynodes.c | 3 --- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/changes/ticket40360 b/changes/ticket40360 new file mode 100644 index 0000000000..4a1b2c3446 --- /dev/null +++ b/changes/ticket40360 @@ -0,0 +1,5 @@ + o Minor bugfixes (bridge, pluggable transport): + - Fix a regression that prevented to configure a Bridge line without a + fingerprint (which is a normal use case). Fixes bug 40360; bugfix on + 0.4.5.4-rc. + diff --git a/src/feature/client/entrynodes.c b/src/feature/client/entrynodes.c index 232216c521..82866ea668 100644 --- a/src/feature/client/entrynodes.c +++ b/src/feature/client/entrynodes.c @@ -804,9 +804,6 @@ get_sampled_guard_for_bridge(guard_selection_t *gs, entry_guard_t *guard; if (BUG(!addrport)) return NULL; // LCOV_EXCL_LINE - if (bridge_has_invalid_transport(bridge)) { - return NULL; - } guard = get_sampled_guard_by_bridge_addr(gs, addrport); if (! guard || (id && tor_memneq(id, guard->identity, DIGEST_LEN))) return NULL;

1 0

[snowflake-webext/master] bump version to 0.5.4
by cohosh＠torproject.org 13 Apr '21

13 Apr '21

commit d2599da5a0149372e88ca744715c34429b9251fe Author: Cecylia Bocovich <cohosh(a)torproject.org> Date: Mon Apr 12 16:24:47 2021 -0400 bump version to 0.5.4 --- package.json | 4 ++-- translation | 2 +- webext/manifest.json | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/package.json b/package.json index eccee94..d22eb11 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "snowflake-pt", - "version": "0.5.3", + "version": "0.5.4", "description": "Snowflake is a WebRTC pluggable transport for Tor.", "main": "build/snowflake.js", "directories": { @@ -33,4 +33,4 @@ "ws": "^3.3.1", "xmlhttprequest": "^1.8.0" } -} +} \ No newline at end of file diff --git a/translation b/translation index 3628de8..92bbac1 160000 --- a/translation +++ b/translation @@ -1 +1 @@ -Subproject commit 3628de8b4e231f1a6a1ae93d665612a807212b17 +Subproject commit 92bbac198ffb95ac84841b5877704810ebfd0038 diff --git a/webext/manifest.json b/webext/manifest.json index d8031e8..504b664 100644 --- a/webext/manifest.json +++ b/webext/manifest.json @@ -1,7 +1,7 @@ { "manifest_version": 2, "name": "Snowflake", - "version": "0.5.3", + "version": "0.5.4", "description": "__MSG_appDesc__", "default_locale": "en_US", "background": {

1 0

[community/master] added space
by gus＠torproject.org 13 Apr '21

13 Apr '21

commit bd95258d545fe5f562b9a348022c2dbdf41d28c9 Author: Anushka Jain <anushkajain2902(a)gmail.com> Date: Tue Apr 13 01:34:49 2021 +0530 added space --- templates/relay-operations.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/templates/relay-operations.html b/templates/relay-operations.html index 7690b3b..1109d78 100644 --- a/templates/relay-operations.html +++ b/templates/relay-operations.html @@ -21,7 +21,7 @@ </div> <div class="row py-5 text-center mx-auto"> <h2 class="display-4 text-primary text-center mx-auto my-3">{{ _('Connect with other Relay Operators') }}</h2> - <p class="text-center">{{ _('The best resource of all is the active community of relay operators on tor-relays mailing list and on IRC #tor-relays in irc.oftc.net. ') }}</p> + <p class="text-center">{{ _('The best resource of all is the active community of relay operators on tor-relays mailing list and on IRC') }} <a href="https://webchat.oftc.net/?channels=tor-relays" target="_blank">{{_('#tor-relays') }}</a> {{ _('in irc.oftc.net.') }}</p> <a class="btn btn-lg btn-outline-primary mx-auto my-3" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"> {{ _('Relay Operators mailing list') }}<i class="ml-3 pt-2 fas fa-arrow-right"></i> </a>

1 0

[tpo/master] Update download-tor.html
by gus＠torproject.org 13 Apr '21

13 Apr '21

commit 6894b091d8356d200ff9b8f256c715e522922bef Author: Burnleydev1 <81782853+Burnleydev1(a)users.noreply.github.com> Date: Mon Apr 12 08:53:40 2021 -0700 Update download-tor.html Vista, XP, 2000, 2003 Server, ME, and Windows 98SE" are not in conformity with this statement "Supported Windows (>= 7) and Windows Server (>= 2008)" in SupportedPlatforms and needs to be removed since they no longer receive updates from Microsoft, not also supported. --- templates/download-tor.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/templates/download-tor.html b/templates/download-tor.html index c4e689b5..dfa53f73 100644 --- a/templates/download-tor.html +++ b/templates/download-tor.html @@ -43,7 +43,7 @@ <table class="table"> <tbody> <tr> - <td>{{ _('Windows 10, 8, 7, Vista, XP, 2000, 2003 Server, ME, and Windows 98SE') }}</td> + <td>{{ _('Windows 10, 8, 7, and Windows Server (>= 2008)') }}</td> <td>{{ _('Contains just Tor and nothing else.') }}</td> <td class="text-right"> {% from "macros/downloads.html" import render_windows_expert %}

1 0

[tpo/master] Merge branch 'fix-issue-173'
by gus＠torproject.org 13 Apr '21

13 Apr '21

commit 54a6701b1e2655d880f4e5f737b3e54dd199329f Merge: 343cfb40 6894b091 Author: gus <gus(a)torproject.org> Date: Mon Apr 12 16:57:57 2021 -0300 Merge branch 'fix-issue-173' templates/download-tor.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

1 0

[community/master] Add advanced usage instructions for obfs4 docker
by gus＠torproject.org 12 Apr '21

12 Apr '21

commit e1867cb683195a4a41e3a6344a994e247d28c86f Author: Cecylia Bocovich <cohosh(a)torproject.org> Date: Mon Apr 12 13:10:35 2021 -0400 Add advanced usage instructions for obfs4 docker We just merged a contribution that allows users to specify arbitrary torrc options for their docker-based obfs4 bridge. This adds instructions for how to configure a bridge with these options and a link to an example .env file. --- .../technical-setup/bridge/docker/contents.lr | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/content/relay-operations/technical-setup/bridge/docker/contents.lr b/content/relay-operations/technical-setup/bridge/docker/contents.lr index aaf89fc..6448ba3 100644 --- a/content/relay-operations/technical-setup/bridge/docker/contents.lr +++ b/content/relay-operations/technical-setup/bridge/docker/contents.lr @@ -73,6 +73,17 @@ obfs4 1.2.3.4:1234 B0E566C9031657EA7ED3FC9D248E8AC4F37635A4 cert=OYWq67L7MDApdJC Make sure to check out the [post-install notes](https://community.torproject.org/relay/setup/bridge/post-install/). If you are having trouble setting up your bridge, have a look at [our help section](https://community.torproject.org/relay/getting-help/). +### 4. Advanced usage + +You may set additional torrc variables in your `.env` file by setting `OBFS4_ENABLE_ADDITIONAL_VARIABLES` to 1 and prefixing the desired torrc options with `OBFS4V_`. For example, to set the `AddressDisableIPv6` option, include the following lines in your `.env`: + +``` +OBFS4_ENABLE_ADDITIONAL_VARIABLES=1 +OBFS4V_AddressDisableIPv6=1 +``` + +You may [download our template .env](https://dip.torproject.org/torproject/anti-censorship/docker-obfs4-bridge/raw/master/.env) to get started. + --- html: two-columns-page.html ---

1 0

[community/master] Update links to gitlab.tpo
by gus＠torproject.org 12 Apr '21

12 Apr '21

commit bb3829c63ee58a710eb5d4ddd6c3dbb99ae5e1ba Author: gus <gus(a)torproject.org> Date: Mon Apr 12 16:11:07 2021 -0300 Update links to gitlab.tpo --- content/relay-operations/technical-setup/bridge/docker/contents.lr | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/content/relay-operations/technical-setup/bridge/docker/contents.lr b/content/relay-operations/technical-setup/bridge/docker/contents.lr index 6448ba3..85ffb24 100644 --- a/content/relay-operations/technical-setup/bridge/docker/contents.lr +++ b/content/relay-operations/technical-setup/bridge/docker/contents.lr @@ -9,7 +9,7 @@ body: ### 1. Deploy a container We provide a docker-compose file that helps you deploy the container. -First, [download docker-compose.yml](https://dip.torproject.org/torproject/anti-censorship/d…, and then write your bridge configuration to a new file, `.env`, which is in the same directory as `docker-compose.yml`. Here's a template: +First, [download docker-compose.yml](https://gitlab.torproject.org/torproject/anti-censorshi…, and then write your bridge configuration to a new file, `.env`, which is in the same directory as `docker-compose.yml`. Here's a template: ``` # Your bridge's Tor port. @@ -82,8 +82,7 @@ OBFS4_ENABLE_ADDITIONAL_VARIABLES=1 OBFS4V_AddressDisableIPv6=1 ``` -You may [download our template .env](https://dip.torproject.org/torproject/anti-censorship/docker-obfs4-bridge/raw/master/.env) to get started. - +You may [download our template .env](https://gitlab.torproject.org/torproject/anti-censorship/docker-obfs4-bridge/raw/master/.env) to get started. --- html: two-columns-page.html ---

1 0