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

[tor/release-0.3.2] ns: Call notify_networkstatus_changed() after the new consensus is set globally
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit 3a247ca92a06c864a2cb634fbe2bc23cf48fb977 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Jan 31 11:08:33 2018 -0500 ns: Call notify_networkstatus_changed() after the new consensus is set globally In 0.3.2.1-alpha, we've added this function in order to have a way to notify other subsystems that the consensus just changed. The old consensus and the new one are passed to it. Before this patch, this was done _before_ the new consensus was set globally (thus NOT accessible by getting the latest consensus). The scheduler notification was assuming that it was set and select_scheduler() is looking at the latest consensus to get the parameters it might needs. This was very wrong because at that point it is still the old consensus set globally. With this commit, notify_networkstatus_changed() has been moved _after_ the new consensus is set globally. The main obvious reasons is to fix the bug described above and in #24975. The other reason is that this notify function doesn't return anything which could be allowing the possibility of refusing to set the new consensus on error. In other words, the new consensus is set right after the notification whatever happens. It does no harm or change in behavior to set the new consensus first and then notify the subsystems. The two functions currently used are for the control port using the old and new consensus and sending the diff. The second is the scheduler that needs the new consensus to be set globally before being called. Of course, the function has been documented accordinly to clearly state it is done _after_ the new consensus is set. Fixes #24975 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug24975 | 6 ++++++ src/or/networkstatus.c | 16 ++++++++++++---- 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/changes/bug24975 b/changes/bug24975 new file mode 100644 index 000000000..fe937d74d --- /dev/null +++ b/changes/bug24975 @@ -0,0 +1,6 @@ + o Major bugfixes (scheduler, consensus): + - A logic in the code was preventing the scheduler subystem to properly + make a decision based on the latest consensus when it arrives. This lead + to the scheduler failing to notice any consensus parameters that might + change from one consensus to another. Fixes bug 24975; bugfix on + 0.3.2.1-alpha. diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c index e0a3e4cdc..4ae114f35 100644 --- a/src/or/networkstatus.c +++ b/src/or/networkstatus.c @@ -1564,7 +1564,11 @@ notify_control_networkstatus_changed(const networkstatus_t *old_c, smartlist_free(changed); } -/* Called when the consensus has changed from old_c to new_c. */ +/* Called when the consensus has changed from old_c to new_c. + * + * IMPORTANT: This is called _after_ the new consensus has been set in the + * global state so this is safe for anything getting the latest consensus from + * that state. */ static void notify_networkstatus_changed(const networkstatus_t *old_c, const networkstatus_t *new_c) @@ -1897,9 +1901,6 @@ networkstatus_set_current_consensus(const char *consensus, const int is_usable_flavor = flav == usable_consensus_flavor(); - if (is_usable_flavor) { - notify_networkstatus_changed(networkstatus_get_latest_consensus(), c); - } if (flav == FLAV_NS) { if (current_ns_consensus) { networkstatus_copy_old_consensus_info(c, current_ns_consensus); @@ -1922,6 +1923,13 @@ networkstatus_set_current_consensus(const char *consensus, free_consensus = 0; /* avoid free */ } + /* Called _after_ the consensus is set in its global variable so any + * functions called from this notification can safely get the latest + * consensus being the new one. */ + if (is_usable_flavor) { + notify_networkstatus_changed(networkstatus_get_latest_consensus(), c); + } + waiting = &consensus_waiting_for_certs[flav]; if (waiting->consensus && waiting->consensus->valid_after <= c->valid_after) {

1 0

[tor/release-0.3.2] Merge remote-tracking branch 'dgoulet/bug24975_032_01' into maint-0.3.2
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit 1c39d969b99b7825a0e2f2db67efb0c0e19d7002 Merge: df312b3cf 3a247ca92 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 31 13:46:58 2018 -0500 Merge remote-tracking branch 'dgoulet/bug24975_032_01' into maint-0.3.2 changes/bug24975 | 6 ++++++ src/or/networkstatus.c | 16 ++++++++++++---- 2 files changed, 18 insertions(+), 4 deletions(-)

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.2' into release-0.3.2
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit 2485f8dea4182cf96696ef3e1b170337a41a5e39 Merge: c35416ab8 1c39d969b Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 31 13:47:01 2018 -0500 Merge branch 'maint-0.3.2' into release-0.3.2 changes/bug24975 | 6 ++++++ src/or/networkstatus.c | 16 ++++++++++++---- 2 files changed, 18 insertions(+), 4 deletions(-)

1 0

[torspec/master] whitespace cleanup.
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit 0a2a40f72bcdca59a7dba44eb42cd197745a6500 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 31 13:45:09 2018 -0500 whitespace cleanup. --- version-spec.txt | 2 -- 1 file changed, 2 deletions(-) diff --git a/version-spec.txt b/version-spec.txt index c97c8ce..f4db300 100644 --- a/version-spec.txt +++ b/version-spec.txt @@ -74,5 +74,3 @@ * Finally, if none of the above conditions hold, then the version is "un-recommended." - -

1 0

[torspec/master] version-spec: specify the different statuses that a version can have
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit ec009108ec08216a111761a7277516a7b26e2252 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Jan 26 12:54:42 2018 -0500 version-spec: specify the different statuses that a version can have --- version-spec.txt | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/version-spec.txt b/version-spec.txt index 1f25cd1..c97c8ce 100644 --- a/version-spec.txt +++ b/version-spec.txt @@ -50,3 +50,29 @@ 0.1.1.1-alpha comes 0.1.1.1-alpha-cvs, and so on. But starting with 0.1.2.1-alpha-dev, we switched to SVN and started using the "-dev" suffix instead of the "-cvs" suffix. + +3. Version status. + + Sometimes we need to determine whether a Tor version is obsolete, + experimental, or neither, based on a list of recommended versions. The + logic is as follows: + + * If a version is listed on the recommended list, then it is + "recommended". + + * If a version is newer than every recommended version, that version + is "experimental" or "new". + + * If a version is older than every recommended version, it is + "obsolete" or "old". + + * The first three components (major,minor,micro) of a version number + are its "release series". If a version has other recommended + versions with the same release series, and the version is newer + than all such recommended versions, but it is not newer than + _every_ recommended version, then the version is "new in series". + + * Finally, if none of the above conditions hold, then the version is + "un-recommended." + +

1 0

[torspec/master] clarify [will become mandatory]
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit 87d662e3a0839ba6eaee167aeda5d7cd95113f31 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 31 13:45:46 2018 -0500 clarify [will become mandatory] --- dir-spec.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dir-spec.txt b/dir-spec.txt index e30a2fd..0e5f048 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -773,7 +773,8 @@ "proto" SP Entries NL - [At most one.] [Will become mandatory.] + [At most one.] + [Will become mandatory at some point after May 2018.] Entries = Entries = Entry

1 0

[tor/maint-0.3.2] hs-v3: Remove a BUG() when storing a descriptor in the client cache
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit df312b3cf637d2c5487adc60ed541823bef56f06 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Jan 31 10:58:11 2018 -0500 hs-v3: Remove a BUG() when storing a descriptor in the client cache It is possible in normal circumstances that a client fetches a descriptor that has a lower revision counter than the one in its cache. This can happen due to HSDir desync. Fixes #24976 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug24976 | 5 +++++ src/or/hs_cache.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/changes/bug24976 b/changes/bug24976 new file mode 100644 index 000000000..9c3be86ea --- /dev/null +++ b/changes/bug24976 @@ -0,0 +1,5 @@ + o Minor bugfixes (hidden service v3 client): + - Remove a BUG() statement which can be triggered in normal circumstances + where a client fetches a descriptor that has a lower revision counter + than the one in its cache. This can happen due to HSDir desync. Fixes + bug 24976; bugfix on 0.3.2.1-alpha. diff --git a/src/or/hs_cache.c b/src/or/hs_cache.c index 3ebe13fb4..6a5a3895b 100644 --- a/src/or/hs_cache.c +++ b/src/or/hs_cache.c @@ -624,8 +624,8 @@ cache_store_as_client(hs_cache_client_descriptor_t *client_desc) if (cache_entry != NULL) { /* If we have an entry in our cache that has a revision counter greater * than the one we just fetched, discard the one we fetched. */ - if (BUG(cache_entry->desc->plaintext_data.revision_counter > - client_desc->desc->plaintext_data.revision_counter)) { + if (cache_entry->desc->plaintext_data.revision_counter > + client_desc->desc->plaintext_data.revision_counter) { cache_client_desc_free(client_desc); goto done; }

1 0

[tor/master] hs-v3: Remove a BUG() when storing a descriptor in the client cache
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit df312b3cf637d2c5487adc60ed541823bef56f06 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Jan 31 10:58:11 2018 -0500 hs-v3: Remove a BUG() when storing a descriptor in the client cache It is possible in normal circumstances that a client fetches a descriptor that has a lower revision counter than the one in its cache. This can happen due to HSDir desync. Fixes #24976 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug24976 | 5 +++++ src/or/hs_cache.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/changes/bug24976 b/changes/bug24976 new file mode 100644 index 000000000..9c3be86ea --- /dev/null +++ b/changes/bug24976 @@ -0,0 +1,5 @@ + o Minor bugfixes (hidden service v3 client): + - Remove a BUG() statement which can be triggered in normal circumstances + where a client fetches a descriptor that has a lower revision counter + than the one in its cache. This can happen due to HSDir desync. Fixes + bug 24976; bugfix on 0.3.2.1-alpha. diff --git a/src/or/hs_cache.c b/src/or/hs_cache.c index 3ebe13fb4..6a5a3895b 100644 --- a/src/or/hs_cache.c +++ b/src/or/hs_cache.c @@ -624,8 +624,8 @@ cache_store_as_client(hs_cache_client_descriptor_t *client_desc) if (cache_entry != NULL) { /* If we have an entry in our cache that has a revision counter greater * than the one we just fetched, discard the one we fetched. */ - if (BUG(cache_entry->desc->plaintext_data.revision_counter > - client_desc->desc->plaintext_data.revision_counter)) { + if (cache_entry->desc->plaintext_data.revision_counter > + client_desc->desc->plaintext_data.revision_counter) { cache_client_desc_free(client_desc); goto done; }

1 0

[tor/release-0.3.2] hs-v3: Remove a BUG() when storing a descriptor in the client cache
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit df312b3cf637d2c5487adc60ed541823bef56f06 Author: David Goulet <dgoulet(a)torproject.org> Date: Wed Jan 31 10:58:11 2018 -0500 hs-v3: Remove a BUG() when storing a descriptor in the client cache It is possible in normal circumstances that a client fetches a descriptor that has a lower revision counter than the one in its cache. This can happen due to HSDir desync. Fixes #24976 Signed-off-by: David Goulet <dgoulet(a)torproject.org> --- changes/bug24976 | 5 +++++ src/or/hs_cache.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/changes/bug24976 b/changes/bug24976 new file mode 100644 index 000000000..9c3be86ea --- /dev/null +++ b/changes/bug24976 @@ -0,0 +1,5 @@ + o Minor bugfixes (hidden service v3 client): + - Remove a BUG() statement which can be triggered in normal circumstances + where a client fetches a descriptor that has a lower revision counter + than the one in its cache. This can happen due to HSDir desync. Fixes + bug 24976; bugfix on 0.3.2.1-alpha. diff --git a/src/or/hs_cache.c b/src/or/hs_cache.c index 3ebe13fb4..6a5a3895b 100644 --- a/src/or/hs_cache.c +++ b/src/or/hs_cache.c @@ -624,8 +624,8 @@ cache_store_as_client(hs_cache_client_descriptor_t *client_desc) if (cache_entry != NULL) { /* If we have an entry in our cache that has a revision counter greater * than the one we just fetched, discard the one we fetched. */ - if (BUG(cache_entry->desc->plaintext_data.revision_counter > - client_desc->desc->plaintext_data.revision_counter)) { + if (cache_entry->desc->plaintext_data.revision_counter > + client_desc->desc->plaintext_data.revision_counter) { cache_client_desc_free(client_desc); goto done; }

1 0

[tor/release-0.3.2] Merge branch 'maint-0.3.2' into release-0.3.2
by nickm＠torproject.org 31 Jan '18

31 Jan '18

commit c35416ab8fbb360fded3db875eb252ba1a9b3273 Merge: 8dc3b5ff3 df312b3cf Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Jan 31 12:51:45 2018 -0500 Merge branch 'maint-0.3.2' into release-0.3.2 changes/bug24976 | 5 +++++ src/or/hs_cache.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-)

1 0