February 2020 - tor-commits - lists.torproject.org

[torspec/master] Prop 313: Only Script, No Tor Logs
by teor＠torproject.org 11 Feb '20

11 Feb '20

commit 91356f5db02b6a62afa3061278872b8d607db7ea Author: teor <teor(a)torproject.org> Date: Tue Feb 11 08:32:25 2020 +1000 Prop 313: Only Script, No Tor Logs Remove the tor logs from the proposal, only write a script. (Some of these calculations are medium-term, and are most relevent during Sponsor 55.) Part of 33159. --- proposals/313-relay-ipv6-stats.txt | 87 +++++++++++++++++++------------------- 1 file changed, 44 insertions(+), 43 deletions(-) diff --git a/proposals/313-relay-ipv6-stats.txt b/proposals/313-relay-ipv6-stats.txt index b521e9b..e615afe 100644 --- a/proposals/313-relay-ipv6-stats.txt +++ b/proposals/313-relay-ipv6-stats.txt @@ -7,13 +7,19 @@ Ticket: #33159 0. Abstract - We propose that Tor relays (and bridges) should log the number of relays in - the consensus that support IPv6 extends, and IPv6 client connections. - - We also propose that Tor relays (and bridges) should collect statistics on - IPv6 connections and consumed bandwidth. Like tor's existing connection - and consumed bandwidth statistics, these new IPv6 statistics will be - published in each relay's extra-info descriptor. + We propose that: + * tor relays should collect statistics on IPv6 connections, and + * tor relays and bridges should collect statistics on consumed bandwidth. + Like tor's existing connection and consumed bandwidth statistics, these new + IPv6 statistics will be published in each relay's extra-info descriptor. + + We also plan to write a script that shows the number of relays in the + consensus that support: + * IPv6 extends, and + * IPv6 client connections. + This script will be used for medium-term monitoring, during the deployment + of tor's IPv6 changes in 2020. (See [Proposal 311: Relay IPv6 Reachability] + and [Proposal 312: Relay Auto IPv6 Address].) 1. Introduction @@ -35,12 +41,6 @@ Ticket: #33159 This proposal modifies Tor's behaviour as follows: - Relays, bridges, and directory authorities log the number of relays that - support IPv6 clients, and IPv6 relay reachability checks. They also log the - corresponding consensus weight fractions. - - As an optional change, tor clients may also log this information. - Relays, bridges, and directory authorities collect statistics on: * IPv6 connections, and * IPv6 consumed bandwidth. @@ -69,31 +69,31 @@ Ticket: #33159 in each section should specifically exclude or include these other roles.) Tor clients do not collect any statistics for public reporting. Therefore, - clients are out of scope in this proposal. (Except for some optional changes - to client logs, where they log the number of IPv6 relays in the consensus). + clients are out of scope in this proposal. When this proposal describes Tor's current behaviour, it covers all supported Tor versions (0.3.5.7 to 0.4.2.5), as of January 2020, except where another version is specifically mentioned. -3. Logging IPv6 Relays in the Consensus + This proposal also includes a medium-term monitoring script, which + calculates the number of relays in the consensus that support IPv6 extends, + and IPv6 client connections. + +3. Monitoring IPv6 Relays in the Consensus - We propose that relays (and bridges) log: + We propose writing a script that calculates: * the number of relays, and * the consensus weight fraction of relays, in the consensus that: * have an IPv6 ORPort, - * support IPv6 reachability checks, and - * support IPv6 clients. - - In order to test these changes, and provide easy access to these - statistics, we propose implementing a script that: - * downloads a consensus, and - * calculates and reports these statistics. + * support IPv6 reachability checks, + * support IPv6 clients, and + * support IPv6 reachability checks, and IPv6 clients. - As well as the statistics listed above, this script should also report the - following relay statistic: - * support IPv6 reachability checks and IPv6 clients. + In order to provide easy access to these statistics, we propose + that the script should: + * download a consensus (or read an existing consensus), and + * calculate and report these statistics. The following consensus weight fractions should divide by the total consensus weight: @@ -108,13 +108,12 @@ Ticket: #33159 "Usable Guards" have the Guard flag, but do not have the Exit flag. If the Guard also has the BadExit flag, the Exit flag should be ignored. - We propose that these logs happen whenever tor: - * receives a consensus from a directory server, or - * loads a live, valid, cached consensus from disk. + Note that this definition of "Usable Guards" is only valid when the + consensus contains many more guards than exits. That is, Wgd must be 0 in + the consensus. (See the [Tor Directory Protocol] for more details.) - As an optional change, tor clients may also log this information. Some of - this information is not directly relevant to clients, but these logs may - help developers (and users). + Therefore, the script should check that Wgd is 0. If it is not, the script + should log a warning about the accuracy of the "Usable Guard" statistics. 4. Collecting IPv6 Consumed Bandwidth Statistics @@ -322,21 +321,23 @@ Ticket: #33159 We provide a quick summary of our testing plans. -8.1. Testing IPv6 Relay Consensus Count Logging +8.1. Testing IPv6 Relay Consensus Calculations - We propose to test these changes using chutney networks. However, chutney - creates a limited number of relays, so we also need to test these changes - on the public tor network. + We propose to test the IPv6 Relay consensus script using chutney networks. + However, chutney creates a limited number of relays, so we also need to + test these changes on consensuses from the public tor network. - Therefore, we propose to test these changes on the public network with a - small number of relays and bridges. + Some of these calculations are similar to the calculations that tor will do, + to find out if IPv6 reachability checks are reliable. So we may be able to + check the script against tor's reachability logs. (See section 4.3.1 in + [Proposal 311: Relay IPv6 Reachability]: Refusing to Publish the + Descriptor.) - We can use the script and the tor logs to cross-check these calculations. The Tor Metrics team may also independently check these calculations. - Once these changes are merged, they will be monitored by tor developers, as - more volunteer relay operators deploy the relevant tor versions. (And as the - number of IPv6 relays in the consensus increases.) + Once the script is completed, its output will be monitored by tor + developers, as more volunteer relay operators deploy the relevant tor + versions. (And as the number of IPv6 relays in the consensus increases.) 8.2. Testing IPv6 Extra-Info Statistics

1 0

[torspec/master] Prop 313: Fix title
by teor＠torproject.org 11 Feb '20

11 Feb '20

commit 64c2ef85c50afa3c890d773ff00c64733ab38029 Author: teor <teor(a)torproject.org> Date: Mon Feb 10 16:58:29 2020 +1000 Prop 313: Fix title Part of 33159. --- proposals/313-relay-ipv6-stats.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/313-relay-ipv6-stats.txt b/proposals/313-relay-ipv6-stats.txt index 2452918..b521e9b 100644 --- a/proposals/313-relay-ipv6-stats.txt +++ b/proposals/313-relay-ipv6-stats.txt @@ -1,5 +1,5 @@ Filename: 313-relay-ipv6-stats.txt -Title: Relay IPv6 Statistics +Title: Tor Relay IPv6 Statistics Author: teor Created: 10-February-2020 Status: Draft

1 0

[torspec/master] Proposals: Run reindex.py
by teor＠torproject.org 11 Feb '20

11 Feb '20

commit 8cc8bff1063126bfc5bc9604115230acc7942895 Author: teor <teor(a)torproject.org> Date: Tue Feb 11 11:58:01 2020 +1000 Proposals: Run reindex.py --- proposals/000-index.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 2e01c99..7706b2a 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -233,6 +233,7 @@ Proposals by number: 310 Towards load-balancing in Prop 271 [OPEN] 311 Tor Relay IPv6 Reachability [DRAFT] 312 Tor Relay Automatic IPv6 Address Discovery [DRAFT] +313 Tor Relay IPv6 Statistics [DRAFT] Proposals by status: @@ -248,6 +249,7 @@ Proposals by status: 309 Optimistic SOCKS Data 311 Tor Relay IPv6 Reachability 312 Tor Relay Automatic IPv6 Address Discovery + 313 Tor Relay IPv6 Statistics NEEDS-REVISION: 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x]

1 0

[torspec/master] Prop 313: Add IPv6 bandwidth statistics safety
by teor＠torproject.org 11 Feb '20

11 Feb '20

commit e9a888f01ad86e8a9193de16ae956c8a62f3c6ae Author: teor <teor(a)torproject.org> Date: Tue Feb 11 08:51:47 2020 +1000 Prop 313: Add IPv6 bandwidth statistics safety Also make BandwidthStatistics an optional change. Part of 33159. --- proposals/313-relay-ipv6-stats.txt | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/proposals/313-relay-ipv6-stats.txt b/proposals/313-relay-ipv6-stats.txt index e615afe..7da142a 100644 --- a/proposals/313-relay-ipv6-stats.txt +++ b/proposals/313-relay-ipv6-stats.txt @@ -1,6 +1,6 @@ Filename: 313-relay-ipv6-stats.txt Title: Tor Relay IPv6 Statistics -Author: teor +Author: teor, Karsten Loesing, Nick Mathewson Created: 10-February-2020 Status: Draft Ticket: #33159 @@ -135,20 +135,11 @@ Ticket: #33159 (The IPv4 statistics can be calculated by subtracting the IPv6 statistics from the existing total consumed bandwidth statistics.) - We propose adding a new BandwidthStatistics torrc option and consensus - parameter, which activates reporting of all these statistics. Currently, - the existing statistics are controlled by ExtraInfoStatistics, but we - propose using the new BandwidthStatistics option for them as well. - - The default value of this option should be "auto", which checks the - consensus parameter. If there is no consensus parameter, the default should - be 1. (The existing bandwidth statistics are reported by default.) + We believe that collecting IPv6 consumed bandwidth statistics is about as + safe as the existing IPv4+IPv6 total consumed bandwidth statistics. - TODO: Should we collect IPv6 bandwidth statistics on bridges? - On bridges, should bandwidth statistics be on or off by default? - - If we do want to collect bridge statistics, and we think it's safe, - modify proposals 311 and 312 to allow bridge statistics. + See also section 7.5, which adds a BandwidthStatistics torrc option and + consensus parameter. BandwidthStatistics is an optional change. 5. Collecting IPv6 Connection Statistics @@ -317,6 +308,17 @@ Ticket: #33159 * as a stacked graph, like [Tor Metrics: Advertised and consumed bandwidth by relay flags] +7.5. Add a BandwidthStatistics option + + We propose adding a new BandwidthStatistics torrc option and consensus + parameter, which activates reporting of all these statistics. Currently, + the existing statistics are controlled by ExtraInfoStatistics, but we + propose using the new BandwidthStatistics option for them as well. + + The default value of this option should be "auto", which checks the + consensus parameter. If there is no consensus parameter, the default should + be 1. (The existing bandwidth statistics are reported by default.) + 8. Test Plan We provide a quick summary of our testing plans.

1 0

[torspec/master] Prop 313: Update IPv6 Connection Stats
by teor＠torproject.org 11 Feb '20

11 Feb '20

commit e31ded5bd7769fd86c488b678a74fe877a0fa50c Author: teor <teor(a)torproject.org> Date: Tue Feb 11 09:09:31 2020 +1000 Prop 313: Update IPv6 Connection Stats We currently have enough relays reporting connection stats, but these reports might be a bug. Make the ConnDirectionStatistics consensus paramter into an optional change, depending on the outcome of the bug. Part of 33159. --- proposals/313-relay-ipv6-stats.txt | 51 ++++++++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 18 deletions(-) diff --git a/proposals/313-relay-ipv6-stats.txt b/proposals/313-relay-ipv6-stats.txt index 7da142a..74c1780 100644 --- a/proposals/313-relay-ipv6-stats.txt +++ b/proposals/313-relay-ipv6-stats.txt @@ -143,7 +143,10 @@ Ticket: #33159 5. Collecting IPv6 Connection Statistics - We propose that relays (and bridges) collect IPv6 connection statistics. + We propose that relays (but not bridges) collect IPv6 connection statistics. + + Bridges refuse to collect the existing ConnDirectionStatistics, so we do not + believe it is safe to collect the smaller IPv6 totals on bridges. To minimise development and testing effort, we propose re-using the existing "bidi" code in rephist.c. (This code may require some refactoring, because @@ -159,23 +162,8 @@ Ticket: #33159 statistics can be calculated by subtracting the IPv6 statistics from the existing total connection statistics.) - We propose using the existing ConnDirectionStatistics torrc option, and - adding a consensus parameter with the same name. This option will control - the new and existing connection statistics. - - The default value of this option should be "auto", which checks the - consensus parameter. If there is no consensus parameter, the default should - be 0. (The existing connection direction statistics are reported by - default.) - - TODO: Do enough relays report ConnDirectionStatistics, for accurate IPv6 - connection statistics? - * at least 25% of relays have IPv6 - * at the end of the project, we expect at least 33% of relays to have - deployed tor 0.4.4-stable - - If not, we should turn on ConnDirectionStatistics by default. (Or set the - consensus parameter for a few days, to collect these statistics.) + See also section 7.6, which adds a ConnDirectionStatistics consensus + parameter. This consensus paramter is an optional change. 6. Directory Protocol Specification Changes @@ -319,6 +307,30 @@ Ticket: #33159 consensus parameter. If there is no consensus parameter, the default should be 1. (The existing bandwidth statistics are reported by default.) +7.6. Add a ConnDirectionStatistics consensus parameter + + We propose using the existing ConnDirectionStatistics torrc option, and + adding a consensus parameter with the same name. This option will control + the new and existing connection statistics. + + The default value of this option should be "auto", which checks the + consensus parameter. If there is no consensus parameter, the default should + be 0. + + Bridges refuse to collect the existing ConnDirectionStatistics, so we do not + believe it is safe to collect the smaller IPv6 totals on bridges. The new + consensus parameter should also be ignored on bridges. + + The existing connection direction statistics are not reported by default, + but almost all relays actually report them. For more details, see: + [Ticket 33214: ConnDirectionStatistics is off by default, but most relays + report it]. + + If we fix the ConnDirectionStatistics default in Tor 0.4.4, we should also + implement the ConnDirectionStatistics consensus parameter. Then we can set + the consensus parameter to 1 for a week or two, so we can collect these + statistics. + 8. Test Plan We provide a quick summary of our testing plans. @@ -380,6 +392,9 @@ References: [Relay Search]: https://metrics.torproject.org/rs.html +[Ticket 33214: ConnDirectionStatistics is off by default, but most relays report it]: + https://trac.torproject.org/projects/tor/ticket/12377 + [Tor Directory Protocol]: (version 3) https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt

1 0

[torspec/master] Prop 311 & 312: Update monitoring based on 313
by teor＠torproject.org 11 Feb '20

11 Feb '20

commit a0492dd33cfc9d210fd9a4f762b779f452591668 Author: teor <teor(a)torproject.org> Date: Tue Feb 11 08:53:14 2020 +1000 Prop 311 & 312: Update monitoring based on 313 Keep the monitoring summaries in proposals 311 and 312 in sync with proposal 313. Part of 33159. --- proposals/311-relay-ipv6-reachability.txt | 16 ++++++++-------- proposals/312-relay-auto-ipv6-addr.txt | 20 +++++++++----------- 2 files changed, 17 insertions(+), 19 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 9f536d3..fd131e1 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -731,23 +731,23 @@ Ticket: #24404 7. Ongoing Monitoring - To monitor the impact of these changes, relays should collect basic IPv4 - and IPv6 connection and bandwidth statistics (see [Proposal 313: Relay IPv6 - Statistics]). - - We may also collect separate statistics on connections from: - * clients (and bridges, because they act like clients), and - * other relays (and authorities, because they act like relays). + To monitor the impact of these changes: + * relays should collect basic IPv6 connection statistics, and + * relays and bridges should collect basic IPv6 bandwidth statistics. + (See [Proposal 313: Relay IPv6 Statistics]). Some of these statistics may be included in tor's heartbeat logs, making them accessible to relay operators. We do not propose to collect additional statistics on: - * bridges, * circuit counts, or * failure rates. Collecting statistics like these could impact user privacy. + We also plan to write a script to calculate the number of IPv6 relays in + the consensus. This script will help us monitor the network during the + deployment of these new IPv6 features. + 8. Changes to Other Proposals [Proposal 306: Client Auto IPv6 Connections] needs to be modified to keep diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index 5228c6c..659e5a1 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -1479,24 +1479,22 @@ Ticket: #33073 6. Ongoing Monitoring - To monitor the impact of these changes, relays should collect basic IPv4 - and IPv6 connection and bandwidth statistics (see [Proposal 313: Relay IPv6 - Statistics]). - - We may also collect separate statistics on connections from: - * clients (and bridges, because they act like clients), and - * other relays (and authorities, because they act like relays). + To monitor the impact of these changes: + * relays should collect basic IPv6 connection statistics, and + * relays and bridges should collect basic IPv6 bandwidth statistics. + (See [Proposal 313: Relay IPv6 Statistics]). Some of these statistics may be included in tor's heartbeat logs, making them accessible to relay operators. We do not propose to collect additional statistics on: - * bridges, - * address resolution, * circuit counts, or * failure rates. - Collecting statistics like these could impact user privacy, or relay - security. + Collecting statistics like these could impact user privacy. + + We also plan to write a script to calculate the number of IPv6 relays in + the consensus. This script will help us monitor the network during the + deployment of these new IPv6 features. 7. Changes to Other Proposals

1 0

[stem/master] Drop tests for invalid signing argument
by atagar＠torproject.org 11 Feb '20

11 Feb '20

commit 91ef638728b398fcfed01ea243afecaf488b1fb7 Author: Damian Johnson <atagar(a)torproject.org> Date: Mon Feb 10 17:39:59 2020 -0800 Drop tests for invalid signing argument Oops, I forgot to install cryptography under python 3.7 so I didn't exercise several tests. This doesn't fix all the failures but corrects the most obvious (we removed the sign argument when it was irrelevant). --- test/unit/descriptor/extrainfo_descriptor.py | 5 ----- test/unit/descriptor/hidden_service_v2.py | 4 ---- test/unit/descriptor/microdescriptor.py | 4 ---- test/unit/descriptor/networkstatus/directory_authority.py | 4 ---- test/unit/descriptor/networkstatus/document_v2.py | 4 ---- test/unit/descriptor/networkstatus/document_v3.py | 4 ---- test/unit/descriptor/networkstatus/key_certificate.py | 4 ---- test/unit/descriptor/router_status_entry.py | 6 ------ test/unit/descriptor/server_descriptor.py | 1 - 9 files changed, 36 deletions(-) diff --git a/test/unit/descriptor/extrainfo_descriptor.py b/test/unit/descriptor/extrainfo_descriptor.py index 6eea7fde..25cbf489 100644 --- a/test/unit/descriptor/extrainfo_descriptor.py +++ b/test/unit/descriptor/extrainfo_descriptor.py @@ -142,11 +142,6 @@ k0d2aofcVbHr4fPQOSST0LXDrhFl5Fqo5um296zpJGvRUeO6S44U/EfJAGShtqWw self.assertEqual('@type bridge-extra-info 1.0', str(desc.type_annotation())) - @test.require.cryptography - def test_descriptor_signing(self): - RelayExtraInfoDescriptor.create(sign = True) - self.assertRaisesWith(NotImplementedError, 'Signing of BridgeExtraInfoDescriptor not implemented', BridgeExtraInfoDescriptor.create, sign = True) - def test_multiple_metrics_bridge_descriptors(self): """ Check that we can read bridge descriptors when there's multiple in a file. diff --git a/test/unit/descriptor/hidden_service_v2.py b/test/unit/descriptor/hidden_service_v2.py index fd90f693..54553d03 100644 --- a/test/unit/descriptor/hidden_service_v2.py +++ b/test/unit/descriptor/hidden_service_v2.py @@ -278,10 +278,6 @@ class TestHiddenServiceDescriptorV2(unittest.TestCase): self.assertEqual([2, 3], desc.protocol_versions) @test.require.cryptography - def test_descriptor_signing(self): - self.assertRaisesWith(NotImplementedError, 'Signing of HiddenServiceDescriptorV2 not implemented', HiddenServiceDescriptorV2.create, sign = True) - - @test.require.cryptography def test_with_basic_auth(self): """ Parse a descriptor with introduction-points encrypted with basic auth. diff --git a/test/unit/descriptor/microdescriptor.py b/test/unit/descriptor/microdescriptor.py index 8d2c07e7..b0b8ebaf 100644 --- a/test/unit/descriptor/microdescriptor.py +++ b/test/unit/descriptor/microdescriptor.py @@ -98,10 +98,6 @@ class TestMicrodescriptor(unittest.TestCase): self.assertEqual({}, desc.protocols) self.assertEqual([], desc.get_unrecognized_lines()) - @test.require.cryptography - def test_descriptor_signing(self): - self.assertRaisesWith(NotImplementedError, 'Signing of Microdescriptor not implemented', Microdescriptor.create, sign = True) - def test_unrecognized_line(self): """ Includes unrecognized content in the descriptor. diff --git a/test/unit/descriptor/networkstatus/directory_authority.py b/test/unit/descriptor/networkstatus/directory_authority.py index 325fad12..6153aa64 100644 --- a/test/unit/descriptor/networkstatus/directory_authority.py +++ b/test/unit/descriptor/networkstatus/directory_authority.py @@ -52,10 +52,6 @@ class TestDirectoryAuthority(unittest.TestCase): self.assertEqual(None, authority.legacy_dir_key) self.assertEqual([], authority.get_unrecognized_lines()) - @test.require.cryptography - def test_descriptor_signing(self): - self.assertRaisesWith(NotImplementedError, 'Signing of DirectoryAuthority not implemented', DirectoryAuthority.create, sign = True) - def test_unrecognized_line(self): """ Includes unrecognized content in the descriptor. diff --git a/test/unit/descriptor/networkstatus/document_v2.py b/test/unit/descriptor/networkstatus/document_v2.py index 7dcc235b..7fb96328 100644 --- a/test/unit/descriptor/networkstatus/document_v2.py +++ b/test/unit/descriptor/networkstatus/document_v2.py @@ -104,7 +104,3 @@ TpQQk3nNQF8z6UIvdlvP+DnJV4izWVkQEZgUZgIVM0E= self.assertEqual([], document.server_versions) self.assertEqual([], document.options) self.assertEqual('moria2', document.signing_authority) - - @test.require.cryptography - def test_descriptor_signing(self): - self.assertRaisesWith(NotImplementedError, 'Signing of NetworkStatusDocumentV2 not implemented', NetworkStatusDocumentV2.create, sign = True) diff --git a/test/unit/descriptor/networkstatus/document_v3.py b/test/unit/descriptor/networkstatus/document_v3.py index 62ce6073..3e3b6953 100644 --- a/test/unit/descriptor/networkstatus/document_v3.py +++ b/test/unit/descriptor/networkstatus/document_v3.py @@ -358,10 +358,6 @@ DnN5aFtYKiTc19qIC7Nmo+afPdDEf0MlJvEOP5EWl3w= self.assertEqual({}, document.bandwidth_weights) self.assertEqual([], document.get_unrecognized_lines()) - @test.require.cryptography - def test_descriptor_signing(self): - self.assertRaisesWith(NotImplementedError, 'Signing of NetworkStatusDocumentV3 not implemented', NetworkStatusDocumentV3.create, sign = True) - def test_examples(self): """ Run something similar to the examples in the header pydocs. diff --git a/test/unit/descriptor/networkstatus/key_certificate.py b/test/unit/descriptor/networkstatus/key_certificate.py index 985610fb..ee5cd92c 100644 --- a/test/unit/descriptor/networkstatus/key_certificate.py +++ b/test/unit/descriptor/networkstatus/key_certificate.py @@ -140,10 +140,6 @@ GM9hAsAMRX9Ogqhq5UjDNqEsvDKuyVeyh7unSZEOip9Zr6K/+7VsVPNb8vfBRBjo self.assertEqual(expected_key_cert, cert.certification) self.assertEqual([], cert.get_unrecognized_lines()) - @test.require.cryptography - def test_descriptor_signing(self): - self.assertRaisesWith(NotImplementedError, 'Signing of KeyCertificate not implemented', KeyCertificate.create, sign = True) - def test_unrecognized_line(self): """ Includes unrecognized content in the descriptor. diff --git a/test/unit/descriptor/router_status_entry.py b/test/unit/descriptor/router_status_entry.py index 3aa02ecc..4b2837b8 100644 --- a/test/unit/descriptor/router_status_entry.py +++ b/test/unit/descriptor/router_status_entry.py @@ -175,12 +175,6 @@ class TestRouterStatusEntry(unittest.TestCase): self.assertEqual('aiUklwBrua82obG5AsTX+iEpkjQA2+AQHxZ7GwMfY70', entry.microdescriptor_digest) self.assertEqual([], entry.get_unrecognized_lines()) - @test.require.cryptography - def test_descriptor_signing(self): - self.assertRaisesWith(NotImplementedError, 'Signing of RouterStatusEntryV2 not implemented', RouterStatusEntryV2.create, sign = True) - self.assertRaisesWith(NotImplementedError, 'Signing of RouterStatusEntryV3 not implemented', RouterStatusEntryV3.create, sign = True) - self.assertRaisesWith(NotImplementedError, 'Signing of RouterStatusEntryMicroV3 not implemented', RouterStatusEntryMicroV3.create, sign = True) - def test_without_ed25519(self): """ Parses a router status entry without a ed25519 value. diff --git a/test/unit/descriptor/server_descriptor.py b/test/unit/descriptor/server_descriptor.py index 6524f9d8..99eb2d27 100644 --- a/test/unit/descriptor/server_descriptor.py +++ b/test/unit/descriptor/server_descriptor.py @@ -261,7 +261,6 @@ Qlx9HNCqCY877ztFRC624ja2ql6A2hBcuoYMbkHjcQ4= @test.require.cryptography def test_descriptor_signing(self): RelayDescriptor.create(sign = True) - self.assertRaisesWith(NotImplementedError, 'Signing of BridgeDescriptor not implemented', BridgeDescriptor.create, sign = True) def test_router_status_entry(self): """

1 0

[tor/master] Update to 0.4.3.2-alpha-dev
by nickm＠torproject.org 11 Feb '20

11 Feb '20

commit 5d56c1f4b29c79d17002872c70e6bb2d561cd2ba Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Feb 10 19:42:31 2020 -0500 Update to 0.4.3.2-alpha-dev --- configure.ac | 4 ++-- contrib/win32build/tor-mingw.nsi.in | 2 +- src/win32/orconfig.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index e31b5751f..009d23aaa 100644 --- a/configure.ac +++ b/configure.ac @@ -4,7 +4,7 @@ dnl Copyright (c) 2007-2019, The Tor Project, Inc. dnl See LICENSE for licensing information AC_PREREQ([2.63]) -AC_INIT([tor],[0.4.3.2-alpha]) +AC_INIT([tor],[0.4.3.2-alpha-dev]) AC_CONFIG_SRCDIR([src/app/main/tor_main.c]) AC_CONFIG_MACRO_DIR([m4]) @@ -16,7 +16,7 @@ configure_flags="$*" # version number changes. Tor uses it to make sure that it # only shuts down for missing "required protocols" when those protocols # are listed as required by a consensus after this date. -AC_DEFINE(APPROX_RELEASE_DATE, ["2020-02-10"], # for 0.4.3.2-alpha +AC_DEFINE(APPROX_RELEASE_DATE, ["2020-02-11"], # for 0.4.3.2-alpha-dev [Approximate date when this software was released. (Updated when the version changes.)]) # "foreign" means we don't follow GNU package layout standards diff --git a/contrib/win32build/tor-mingw.nsi.in b/contrib/win32build/tor-mingw.nsi.in index 6e5775a5e..8b7cafb4a 100644 --- a/contrib/win32build/tor-mingw.nsi.in +++ b/contrib/win32build/tor-mingw.nsi.in @@ -8,7 +8,7 @@ !include "LogicLib.nsh" !include "FileFunc.nsh" !insertmacro GetParameters -!define VERSION "0.4.3.2-alpha" +!define VERSION "0.4.3.2-alpha-dev" !define INSTALLER "tor-${VERSION}-win32.exe" !define WEBSITE "https://www.torproject.org/" !define LICENSE "LICENSE" diff --git a/src/win32/orconfig.h b/src/win32/orconfig.h index 5422c9748..7154b30f9 100644 --- a/src/win32/orconfig.h +++ b/src/win32/orconfig.h @@ -217,7 +217,7 @@ #define USING_TWOS_COMPLEMENT /* Version number of package */ -#define VERSION "0.4.3.2-alpha" +#define VERSION "0.4.3.2-alpha-dev" #define HAVE_STRUCT_SOCKADDR_IN6 #define HAVE_STRUCT_IN6_ADDR

1 0

[tor/master] Merge branch 'maint-0.4.3'
by nickm＠torproject.org 11 Feb '20

11 Feb '20

commit dac185edbae6b4802e517d744891bb831e863880 Merge: dcbf6611d 5d56c1f4b Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Feb 10 19:43:17 2020 -0500 Merge branch 'maint-0.4.3' "ours" merge to avoid version bump.

1 0

[tor/master] Update to 0.4.4.0-alpha-dev
by nickm＠torproject.org 11 Feb '20

11 Feb '20

commit 71d96cefc0314bc3ad6cad867586c492a287c6c9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Feb 10 19:43:54 2020 -0500 Update to 0.4.4.0-alpha-dev --- configure.ac | 4 ++-- contrib/win32build/tor-mingw.nsi.in | 2 +- src/win32/orconfig.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index e31b5751f..aa511a391 100644 --- a/configure.ac +++ b/configure.ac @@ -4,7 +4,7 @@ dnl Copyright (c) 2007-2019, The Tor Project, Inc. dnl See LICENSE for licensing information AC_PREREQ([2.63]) -AC_INIT([tor],[0.4.3.2-alpha]) +AC_INIT([tor],[0.4.4.0-alpha-dev]) AC_CONFIG_SRCDIR([src/app/main/tor_main.c]) AC_CONFIG_MACRO_DIR([m4]) @@ -16,7 +16,7 @@ configure_flags="$*" # version number changes. Tor uses it to make sure that it # only shuts down for missing "required protocols" when those protocols # are listed as required by a consensus after this date. -AC_DEFINE(APPROX_RELEASE_DATE, ["2020-02-10"], # for 0.4.3.2-alpha +AC_DEFINE(APPROX_RELEASE_DATE, ["2020-02-11"], # for 0.4.4.0-alpha-dev [Approximate date when this software was released. (Updated when the version changes.)]) # "foreign" means we don't follow GNU package layout standards diff --git a/contrib/win32build/tor-mingw.nsi.in b/contrib/win32build/tor-mingw.nsi.in index 6e5775a5e..fb13a2eb3 100644 --- a/contrib/win32build/tor-mingw.nsi.in +++ b/contrib/win32build/tor-mingw.nsi.in @@ -8,7 +8,7 @@ !include "LogicLib.nsh" !include "FileFunc.nsh" !insertmacro GetParameters -!define VERSION "0.4.3.2-alpha" +!define VERSION "0.4.4.0-alpha-dev" !define INSTALLER "tor-${VERSION}-win32.exe" !define WEBSITE "https://www.torproject.org/" !define LICENSE "LICENSE" diff --git a/src/win32/orconfig.h b/src/win32/orconfig.h index 5422c9748..3c8f91d53 100644 --- a/src/win32/orconfig.h +++ b/src/win32/orconfig.h @@ -217,7 +217,7 @@ #define USING_TWOS_COMPLEMENT /* Version number of package */ -#define VERSION "0.4.3.2-alpha" +#define VERSION "0.4.4.0-alpha-dev" #define HAVE_STRUCT_SOCKADDR_IN6 #define HAVE_STRUCT_IN6_ADDR

1 0