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

[tor/release-0.3.5] Merge branch 'rust-panic1' into rust-panic1-034
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit 5ab5c8ec15de7a54c9196b9adcfda6042d4db5e4 Merge: 48e990359 fecd583c0 Author: teor <teor(a)torproject.org> Date: Mon Apr 15 10:15:02 2019 +1000 Merge branch 'rust-panic1' into rust-panic1-034 changes/bug27199 | 3 +++ src/rust/Cargo.toml | 10 ++++++++++ 2 files changed, 13 insertions(+) diff --cc src/rust/Cargo.toml index c3e44d2a7,c22eea984..de8693ea3 --- a/src/rust/Cargo.toml +++ b/src/rust/Cargo.toml @@@ -1,15 -1,11 +1,20 @@@ [workspace] -members = ["tor_util", "protover", "smartlist", "external", "tor_allocate", "tor_rust"] +members = [ + "crypto", + "external", + "protover", + "smartlist", + "tor_allocate", + "tor_log", + "tor_rust", + "tor_util", +] + # Can remove panic="abort" when this issue is fixed: + # https://github.com/rust-lang/rust/issues/52652 + [profile.dev] + panic = "abort" + [profile.release] debug = true panic = "abort"

1 0

[tor/release-0.3.5] Log the correct "auto" port number for listening sockets
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit 389ee834b6795ccabbe3d4c7edfdaf8d89696438 Author: Kris Katterjohn <katterjohn(a)gmail.com> Date: Mon Jan 21 13:12:53 2019 -0600 Log the correct "auto" port number for listening sockets When "auto" was used for the port number for a listening socket, the message logged after opening the socket would incorrectly say port 0 instead of the actual port used. Fixes bug 29144; bugfix on 0.3.5.1-alpha Signed-off-by: Kris Katterjohn <katterjohn(a)gmail.com> --- changes/bug29144 | 5 +++++ src/core/mainloop/connection.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/changes/bug29144 b/changes/bug29144 new file mode 100644 index 000000000..5801224f1 --- /dev/null +++ b/changes/bug29144 @@ -0,0 +1,5 @@ + o Minor bugfixes (logging): + - Log the correct port number for listening sockets when "auto" is + used to let Tor pick the port number. Previously, port 0 was + logged instead of the actual port number. Fixes bug 29144; + bugfix on 0.3.5.1-alpha. Patch from Kris Katterjohn. diff --git a/src/core/mainloop/connection.c b/src/core/mainloop/connection.c index f2a646c5f..7b8dc7f36 100644 --- a/src/core/mainloop/connection.c +++ b/src/core/mainloop/connection.c @@ -1527,7 +1527,7 @@ connection_listener_new(const struct sockaddr *listensockaddr, conn_type_to_string(type), conn->address); } else { log_notice(LD_NET, "Opened %s on %s", - conn_type_to_string(type), fmt_addrport(&addr, usePort)); + conn_type_to_string(type), fmt_addrport(&addr, gotPort)); } return conn;

1 0

[tor/release-0.3.4] Merge remote-tracking branch 'tor-github/pr/946' into maint-0.3.4
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit 116970dda7d04bfdc1cff0034d5ee9969a6754c4 Merge: b1762f8d1 5ab5c8ec1 Author: teor <teor(a)torproject.org> Date: Fri Apr 19 11:47:10 2019 +1000 Merge remote-tracking branch 'tor-github/pr/946' into maint-0.3.4 changes/bug27199 | 3 +++ src/rust/Cargo.toml | 10 ++++++++++ 2 files changed, 13 insertions(+)

1 0

[tor/release-0.3.5] relays shouldn't close idle rend circuits
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit add0f89c14b4aab6726e11acdcd864ee0c91543b Author: Roger Dingledine <arma(a)torproject.org> Date: Sat Mar 9 02:55:28 2019 -0500 relays shouldn't close idle rend circuits Allow connections to single onion services to remain idle without being disconnected. Relays acting as rendezvous points for single onion services were mistakenly closing idle established rendezvous circuits after 60 seconds, thinking that they are unused directory-fetching circuits that had served their purpose. Fixes bug 29665; bugfix on 0.2.1.26. --- changes/bug29665 | 7 +++++++ src/or/circuituse.c | 5 ++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/changes/bug29665 b/changes/bug29665 new file mode 100644 index 000000000..d89046faf --- /dev/null +++ b/changes/bug29665 @@ -0,0 +1,7 @@ + o Minor bugfixes (single onion services): + - Allow connections to single onion services to remain idle without + being disconnected. Relays acting as rendezvous points for + single onion services were mistakenly closing idle established + rendezvous circuits after 60 seconds, thinking that they are unused + directory-fetching circuits that had served their purpose. Fixes + bug 29665; bugfix on 0.2.1.26. diff --git a/src/or/circuituse.c b/src/or/circuituse.c index 96cd3cd7e..7c0b60293 100644 --- a/src/or/circuituse.c +++ b/src/or/circuituse.c @@ -1381,10 +1381,13 @@ circuit_expire_old_circuits_serverside(time_t now) or_circ = TO_OR_CIRCUIT(circ); /* If the circuit has been idle for too long, and there are no streams * on it, and it ends here, and it used a create_fast, mark it for close. + * + * Also if there is a rend_splice on it, it's a single onion service + * circuit and we should not close it. */ if (or_circ->is_first_hop && !circ->n_chan && !or_circ->n_streams && !or_circ->resolving_streams && - or_circ->p_chan && + or_circ->p_chan && !or_circ->rend_splice && channel_when_last_xmit(or_circ->p_chan) <= cutoff) { log_info(LD_CIRC, "Closing circ_id %u (empty %d secs ago)", (unsigned)or_circ->p_circ_id,

1 0

[tor/release-0.3.4] Merge branch 'maint-0.3.4' into release-0.3.4
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit fa6296df3afb6824f0610aabaef486c4b4b4c82c Merge: 2afba291b cbce8dedd Author: teor <teor(a)torproject.org> Date: Fri Apr 19 12:00:36 2019 +1000 Merge branch 'maint-0.3.4' into release-0.3.4 changes/bug27199 | 3 +++ changes/bug29017 | 4 ++++ changes/bug29665 | 7 +++++++ doc/tor.1.txt | 2 +- src/or/circuituse.c | 4 ++++ src/or/router.c | 11 +++++------ src/rust/Cargo.toml | 10 ++++++++++ 7 files changed, 34 insertions(+), 7 deletions(-)

1 0

[tor/release-0.3.5] relays shouldn't close idle rend circuits
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit a3bc950e4201fe49e7a0996753a4af83d822828b Author: Roger Dingledine <arma(a)torproject.org> Date: Sat Mar 9 03:18:25 2019 -0500 relays shouldn't close idle rend circuits Allow connections to single onion services to remain idle without being disconnected. Relays acting as rendezvous points for single onion services were mistakenly closing idle established rendezvous circuits after 60 seconds, thinking that they are unused directory-fetching circuits that had served their purpose. Fixes bug 29665; bugfix on 0.2.1.26. --- changes/bug29665 | 7 +++++++ src/or/circuituse.c | 4 ++++ 2 files changed, 11 insertions(+) diff --git a/changes/bug29665 b/changes/bug29665 new file mode 100644 index 000000000..d89046faf --- /dev/null +++ b/changes/bug29665 @@ -0,0 +1,7 @@ + o Minor bugfixes (single onion services): + - Allow connections to single onion services to remain idle without + being disconnected. Relays acting as rendezvous points for + single onion services were mistakenly closing idle established + rendezvous circuits after 60 seconds, thinking that they are unused + directory-fetching circuits that had served their purpose. Fixes + bug 29665; bugfix on 0.2.1.26. diff --git a/src/or/circuituse.c b/src/or/circuituse.c index 8e007ce92..03f2ae52c 100644 --- a/src/or/circuituse.c +++ b/src/or/circuituse.c @@ -1560,10 +1560,14 @@ circuit_expire_old_circuits_serverside(time_t now) or_circ = TO_OR_CIRCUIT(circ); /* If the circuit has been idle for too long, and there are no streams * on it, and it ends here, and it used a create_fast, mark it for close. + * + * Also if there is a rend_splice on it, it's a single onion service + * circuit and we should not close it. */ if (or_circ->p_chan && channel_is_client(or_circ->p_chan) && !circ->n_chan && !or_circ->n_streams && !or_circ->resolving_streams && + !or_circ->rend_splice && channel_when_last_xmit(or_circ->p_chan) <= cutoff) { log_info(LD_CIRC, "Closing circ_id %u (empty %d secs ago)", (unsigned)or_circ->p_circ_id,

1 0

[tor/maint-0.2.9] relays shouldn't close idle rend circuits
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit add0f89c14b4aab6726e11acdcd864ee0c91543b Author: Roger Dingledine <arma(a)torproject.org> Date: Sat Mar 9 02:55:28 2019 -0500 relays shouldn't close idle rend circuits Allow connections to single onion services to remain idle without being disconnected. Relays acting as rendezvous points for single onion services were mistakenly closing idle established rendezvous circuits after 60 seconds, thinking that they are unused directory-fetching circuits that had served their purpose. Fixes bug 29665; bugfix on 0.2.1.26. --- changes/bug29665 | 7 +++++++ src/or/circuituse.c | 5 ++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/changes/bug29665 b/changes/bug29665 new file mode 100644 index 000000000..d89046faf --- /dev/null +++ b/changes/bug29665 @@ -0,0 +1,7 @@ + o Minor bugfixes (single onion services): + - Allow connections to single onion services to remain idle without + being disconnected. Relays acting as rendezvous points for + single onion services were mistakenly closing idle established + rendezvous circuits after 60 seconds, thinking that they are unused + directory-fetching circuits that had served their purpose. Fixes + bug 29665; bugfix on 0.2.1.26. diff --git a/src/or/circuituse.c b/src/or/circuituse.c index 96cd3cd7e..7c0b60293 100644 --- a/src/or/circuituse.c +++ b/src/or/circuituse.c @@ -1381,10 +1381,13 @@ circuit_expire_old_circuits_serverside(time_t now) or_circ = TO_OR_CIRCUIT(circ); /* If the circuit has been idle for too long, and there are no streams * on it, and it ends here, and it used a create_fast, mark it for close. + * + * Also if there is a rend_splice on it, it's a single onion service + * circuit and we should not close it. */ if (or_circ->is_first_hop && !circ->n_chan && !or_circ->n_streams && !or_circ->resolving_streams && - or_circ->p_chan && + or_circ->p_chan && !or_circ->rend_splice && channel_when_last_xmit(or_circ->p_chan) <= cutoff) { log_info(LD_CIRC, "Closing circ_id %u (empty %d secs ago)", (unsigned)or_circ->p_circ_id,

1 0

[tor/maint-0.2.9] Merge remote-tracking branch 'tor-github/pr/792' into maint-0.2.9
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit 2460b4461f61c3b0fdeedb5bbfb21847a256a867 Merge: ec213ae8a add0f89c1 Author: teor <teor(a)torproject.org> Date: Fri Apr 19 11:42:09 2019 +1000 Merge remote-tracking branch 'tor-github/pr/792' into maint-0.2.9 changes/bug29665 | 7 +++++++ src/or/circuituse.c | 5 ++++- 2 files changed, 11 insertions(+), 1 deletion(-)

1 0

[tor/maint-0.2.9] hs-v2: Copy needed information between service on prunning
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit b4e44a371f077f5a9fca19f94e6ff5f604f3e9d3 Author: David Goulet <dgoulet(a)torproject.org> Date: Fri Mar 8 09:54:54 2019 -0500 hs-v2: Copy needed information between service on prunning Turns out that when reloading a tor configured with hidden service(s), we weren't copying all the needed information between the old service object to the new one. For instance, the desc_is_dirty timestamp wasn't which could lead to the service uploading its descriptor much later than it would need to. The replaycache wasn't also moved over and some intro point information as well. Fixes #23790 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug23790 | 6 ++++++ src/or/rendservice.c | 27 +++++++++++++++++++++++++++ 2 files changed, 33 insertions(+) diff --git a/changes/bug23790 b/changes/bug23790 new file mode 100644 index 000000000..4aaf616e4 --- /dev/null +++ b/changes/bug23790 @@ -0,0 +1,6 @@ + o Minor bugfixes (hidden service v2): + - When reloading tor (HUP) configured with hidden service(s), some + information weren't copy to the new service object. One problem with this + was that tor would wait at least the RendPostPeriod time before uploading + the descriptor if the reload happened before the descriptor needed to be + published. Fixes bug 23790; bugfix on 0.2.1.9-alpha. diff --git a/src/or/rendservice.c b/src/or/rendservice.c index da200d138..32b856452 100644 --- a/src/or/rendservice.c +++ b/src/or/rendservice.c @@ -532,6 +532,30 @@ rend_service_check_dir_and_add(smartlist_t *service_list, } } +/* Copy relevant data from service src to dst while pruning the service lists. + * This should only be called during the pruning process which takes existing + * services and copy their data to the newly configured services. The src + * service replaycache will be set to NULL after this call. */ +static void +copy_service_on_prunning(rend_service_t *dst, rend_service_t *src) +{ + tor_assert(dst); + tor_assert(src); + + /* Keep the timestamps for when the content changed and the next upload + * time so we can properly upload the descriptor if needed for the new + * service object. */ + dst->desc_is_dirty = src->desc_is_dirty; + dst->next_upload_time = src->next_upload_time; + /* Move the replaycache to the new object. */ + dst->accepted_intro_dh_parts = src->accepted_intro_dh_parts; + src->accepted_intro_dh_parts = NULL; + /* Copy intro point information to destination service. */ + dst->intro_period_started = src->intro_period_started; + dst->n_intro_circuits_launched = src->n_intro_circuits_launched; + dst->n_intro_points_wanted = src->n_intro_points_wanted; +} + /** Set up rend_service_list, based on the values of HiddenServiceDir and * HiddenServicePort in <b>options</b>. Return 0 on success and -1 on * failure. (If <b>validate_only</b> is set, parse, warn and return as @@ -812,6 +836,9 @@ rend_config_services(const or_options_t *options, int validate_only) smartlist_add_all(new->expiring_nodes, old->expiring_nodes); smartlist_clear(old->expiring_nodes); smartlist_add(surviving_services, old); + + /* Copy service flags to the new service object. */ + copy_service_on_prunning(new, old); break; } } SMARTLIST_FOREACH_END(old);

1 0

[tor/maint-0.2.9] Merge remote-tracking branch 'tor-github/pr/772' into maint-0.2.9
by teor＠torproject.org 19 Apr '19

19 Apr '19

commit ec213ae8a09505e97215cf9c54d1003c314c91f9 Merge: a0db5ade3 b4e44a371 Author: teor <teor(a)torproject.org> Date: Fri Apr 19 11:38:52 2019 +1000 Merge remote-tracking branch 'tor-github/pr/772' into maint-0.2.9 changes/bug23790 | 6 ++++++ src/or/rendservice.c | 27 +++++++++++++++++++++++++++ 2 files changed, 33 insertions(+)

1 0