Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:00:10Zhttps://gitlab.torproject.org/legacy/trac/-/issues/19889New guard plan - Glue things together!2020-06-13T15:00:10ZAndrea ShepardNew guard plan - Glue things together!New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
13) Glue things together!
- Add clean and meaningful logging so that we can *heavily* field test the feature in our machinesNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
13) Glue things together!
- Add clean and meaningful logging so that we can *heavily* field test the feature in our machinesTor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19888New guard plan - separate state instances when EntryNodes/ExcludeNodes/etc ar...2020-06-13T15:03:44ZAndrea ShepardNew guard plan - separate state instances when EntryNodes/ExcludeNodes/etc are usedNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
12) Separate state instances when EntryNodes/ExcludeNodes/etc are used
- See prop271 MEANINGFUL_RESTRICTION_FRAC etc.New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
12) Separate state instances when EntryNodes/ExcludeNodes/etc are used
- See prop271 MEANINGFUL_RESTRICTION_FRAC etc.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19887New guard plan - bridge support2020-06-13T15:00:09ZAndrea ShepardNew guard plan - bridge supportNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
11) Bridge support
- Thoughtworks function: fill_in_from_bidges()New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
11) Bridge support
- Thoughtworks function: fill_in_from_bidges()Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19886New guard plan - update state whenever we get a new consensus2020-06-13T15:00:08ZAndrea ShepardNew guard plan - update state whenever we get a new consensusNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
10) Update state whenever we get a new consensus (section ON_CONSENSUS)
- Update SAMPLED_GUARDS elements (section SAMPLED)
- Remove obso...New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
10) Update state whenever we get a new consensus (section ON_CONSENSUS)
- Update SAMPLED_GUARDS elements (section SAMPLED)
- Remove obsolete/expired guards
- See entry_guards_compute_status() / remove_obsolete_entry_guards()
- Thoughtworks function: entry_guards_update_profiles()Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19885New guard plan - update list of waiting circuits2020-06-13T15:00:07ZAndrea ShepardNew guard plan - update list of waiting circuitsNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
9) Update list of waiting circuits (section UPDATE_WAITING)
- Implementation of guard "higher priority" ordering (see CONFIRMED)
- UnittestNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
9) Update list of waiting circuits (section UPDATE_WAITING)
- Implementation of guard "higher priority" ordering (see CONFIRMED)
- UnittestTor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19884Retry schedule for guards per new guard plan2020-06-13T15:00:07ZAndrea ShepardRetry schedule for guards per new guard planNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
8) Retry schedule for guards (section RETRYING)
- See entry_is_time_to_retry()
- UnittestNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
8) Retry schedule for guards (section RETRYING)
- See entry_is_time_to_retry()
- UnittestTor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19883Maintain CONFIRMED_GUARDS per new guard plan2020-06-13T15:00:06ZAndrea ShepardMaintain CONFIRMED_GUARDS per new guard planNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
7) Maintain CONFIRMED_GUARDS
- Add guard to CONFIRMED_GUARDS when circuit succeeds
- Fill in state info for each confirmed guard (confir...New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
7) Maintain CONFIRMED_GUARDS
- Add guard to CONFIRMED_GUARDS when circuit succeeds
- Fill in state info for each confirmed guard (confirmed_on_date, etc.)
- Migration from old state format to new
- Thoughtworks unittest: test_used_guards_parse_state()Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19882New guard plan - update guard state when a circuit fails/succeeds2020-06-13T15:00:06ZAndrea ShepardNew guard plan - update guard state when a circuit fails/succeedsNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
6) Update guard state when a circuit fails/succeeds
- Section ON_FAIL and ON_SUCCESS
- See entry_guard_register_connect_status()
- Unit...New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
6) Update guard state when a circuit fails/succeeds
- Section ON_FAIL and ON_SUCCESS
- See entry_guard_register_connect_status()
- UnittestTor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19881New guard plan - guard selection for circuits2020-06-13T15:00:05ZAndrea ShepardNew guard plan - guard selection for circuitsNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
5) Selecting guards for circuits
- Meant to replace choose_random_entry_impl()
- See section SELECTING in prop271
- Add new circuit sta...New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
5) Selecting guards for circuits
- Meant to replace choose_random_entry_impl()
- See section SELECTING in prop271
- Add new circuit states to or_circuit_t
- Implement the guard selection logic
- Unittests on circuit state machine
- Unittests on guard selection logicTor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19880Maintain set of PRIMARY_GUARDS per new guard plan2020-06-13T15:00:05ZAndrea ShepardMaintain set of PRIMARY_GUARDS per new guard planNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
4) Maintain set of PRIMARY_GUARDS
- Functions to extract set of (live) primary guards out of FILTERED_GUARDS
- Unittest
- Thoughtworks ...New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
4) Maintain set of PRIMARY_GUARDS
- Functions to extract set of (live) primary guards out of FILTERED_GUARDS
- Unittest
- Thoughtworks function: retry_primary_guards() / next_primary_guard()
- Thoughtworks unittests: test_next_primary_guard()Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19879Derive FILTERED_GUARDS / USABLE_FILTERED_GUARDS from SAMPLED_GUARDS per new g...2020-06-13T15:00:04ZAndrea ShepardDerive FILTERED_GUARDS / USABLE_FILTERED_GUARDS from SAMPLED_GUARDS per new guard planNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
3) Derive FILTERED_GUARDS / USABLE_FILTERED_GUARDS from SAMPLED_GUARDS
- The filtering function can be called at any point (e.g. ON_CONSE...New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
3) Derive FILTERED_GUARDS / USABLE_FILTERED_GUARDS from SAMPLED_GUARDS
- The filtering function can be called at any point (e.g. ON_CONSENSUS)
- Write unittests ensuring correctness of filtering
- See populate_live_entry_guards()
- Thoughtworks function: filter_set() / filter_sampled()Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19878Sample SAMPLED_GUARDS from GUARDS per new guard plan2020-06-13T15:00:03ZAndrea ShepardSample SAMPLED_GUARDS from GUARDS per new guard planNew guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
2) Sample SAMPLED_GUARDS from GUARDS
- Fill in state for each sampled guard (added_on_date, etc.)
- Save/load SAMPLED_GUARDS to/from sta...New guard plan summarized at https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.html
2) Sample SAMPLED_GUARDS from GUARDS
- Fill in state for each sampled guard (added_on_date, etc.)
- Save/load SAMPLED_GUARDS to/from state
- Unittests for sampling/saving/loading
- Thoughtworks function: fill_sampled_guards_from_entrynodes()
- Thoughtworks unittest: test_fill_in_sampled_set()Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19877Implement new guard selection algorithm of prop 2712020-06-13T15:03:49ZAndrea ShepardImplement new guard selection algorithm of prop 271Parent ticket for tasks implementing the new guard selection algorithm described in https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.htmlParent ticket for tasks implementing the new guard selection algorithm described in https://lists.torproject.org/pipermail/tor-dev/2016-July/011234.htmlTor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19869tor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-12020-06-13T14:59:58ZIsis Lovecrufttor_fragile_assert() in evdns_get_orig_address() on tor-0.2.9-alpha-1```
│ 15:29:14 [WARN] Bug: /usr/bin/tor(+0x3ee39) [0x56051379ee39] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fa32c454b45] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WAR...```
│ 15:29:14 [WARN] Bug: /usr/bin/tor(+0x3ee39) [0x56051379ee39] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fa32c454b45] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(main+0x19) [0x56051379ede9] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(tor_main+0x1c25) [0x5605137a6cf5] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(do_main_loop+0x294) [0x5605137a3494] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7fa32d6a73dc] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(+0x42451) [0x5605137a2451] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(+0xf59e5) [0x5605138559e5] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(+0xfe584) [0x56051385e584] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(channel_tls_handle_cell+0x233) [0x56051381c303] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(command_process_cell+0x280) [0x560513839ce0] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x2a9) [0x5605137c99e9] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(+0x69673) [0x5605137c9673] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(connection_ap_handshake_socks_resolved+0x9e) [0x56051385876e] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(dnsserv_resolved+0x1dc) [0x56051388f76c] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x5605138be107] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: /usr/bin/tor(log_backtrace+0x42) [0x5605138a56c2] (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] Bug: Line unexpectedly reached at evdns_get_orig_address at ../src/or/dnsserv.c:292. Stack trace: (on Tor 0.2.9.1-alpha )
│ 15:29:14 [WARN] tor_bug_occurred_(): Bug: ../src/or/dnsserv.c:292: evdns_get_orig_address: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.2.9.1-alpha )
```
Possibly related to #18961.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19743VirtualAddrNetworkIPv6 manpage entry correction2020-06-13T14:59:41ZcypherpunksVirtualAddrNetworkIPv6 manpage entry correctionThis section of the manual needs a minor revision.
```
VirtualAddrNetworkIPv6 [Address]/bits
When Tor needs to assign a virtual (unused) address because of a
MAPADDRESS command from the controller or the Aut...This section of the manual needs a minor revision.
```
VirtualAddrNetworkIPv6 [Address]/bits
When Tor needs to assign a virtual (unused) address because of a
MAPADDRESS command from the controller or the AutomapHostsOnResolve
feature, Tor picks an unassigned address from this range.
(Defaults: 127.192.0.0/10 and [FE80::]/10 respectively.)
When providing proxy server service to a network of computers using
a tool like dns-proxy-tor, change the IPv4 network to
"10.192.0.0/10" or "172.16.0.0/12" and change the IPv6 network to
"[FC00]/7".
```
`[FC00]/7` _should_ read `[FC00::]/7`
See [Error configuring tor as transparent proxy with IPv6](https://tor.stackexchange.com/questions/12184/error-configuring-tor-as-transparent-proxy-with-ipv6) on the Tor Stack Exchange.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19678Don't allow hidden services in Tor2web mode2020-06-13T14:59:34ZteorDon't allow hidden services in Tor2web modeThey're not anonymous, so let's not pretend they are.
Part of #17178, opening this to get a bug number.They're not anonymous, so let's not pretend they are.
Part of #17178, opening this to get a bug number.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19677Count unix sockets when counting client listeners2020-06-13T14:59:33ZteorCount unix sockets when counting client listenersIn #17178, we discovered that unix sockets aren't being counted for the client listener *_set options (like SOCKSPort_set). This is required for correct behaviour in #17178.
These variables aren't ever used, so this fix is not user-visi...In #17178, we discovered that unix sockets aren't being counted for the client listener *_set options (like SOCKSPort_set). This is required for correct behaviour in #17178.
These variables aren't ever used, so this fix is not user-visible.
I'm just opening this to get a bug number, the fix is in the #17178 branch.https://gitlab.torproject.org/legacy/trac/-/issues/19663On rend failure, Single Onions should build a 3-hop path2020-06-13T14:59:31ZteorOn rend failure, Single Onions should build a 3-hop pathThis enables two features:
* Single Onion compatibility with Rend Points avoiding being one-hop proxies (#17945)
* In this case, failure is defined as the inability to connect to a rend point with REASON_TORPROTOCOL (or whatever #17945...This enables two features:
* Single Onion compatibility with Rend Points avoiding being one-hop proxies (#17945)
* In this case, failure is defined as the inability to connect to a rend point with REASON_TORPROTOCOL (or whatever #17945 does)
* Single Onion compatibility with ReachableAddresses, in particular:
* IPv6-only Single Onions talking to non-IPv6 intro points
* In this case, failure is defined as the inability to discover a reachable rend pointhttps://gitlab.torproject.org/legacy/trac/-/issues/19419Tor generates different onion "hostname" out of same private key?2020-06-13T14:58:41ZTracTor generates different onion "hostname" out of same private key?When I copy some older private_key files I generated with Shallot time ago to a new tor process, then give it a kill -1, it parses the private_key and produces a different hostname to match it. It's odd because the private key is the one...When I copy some older private_key files I generated with Shallot time ago to a new tor process, then give it a kill -1, it parses the private_key and produces a different hostname to match it. It's odd because the private key is the one that should have the nice name, instead it now gets an ugly new one. Any guess on what I could have done wrong? Apparently nobody else ran into this problem...
**Trac**:
**Username**: vynXTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19357keypin_load_journal_impl() might break if journal file contains NUL2020-06-13T14:58:34ZAndrea Shepardkeypin_load_journal_impl() might break if journal file contains NULThe journal file reader loop in src/or/keypin.c only uses end of file or '\n' to find the end of a line, so if a line contains a NUL we may end up passing a string with one in the middle to other things:
```
367 STATIC int
368 keypin_lo...The journal file reader loop in src/or/keypin.c only uses end of file or '\n' to find the end of a line, so if a line contains a NUL we may end up passing a string with one in the middle to other things:
```
367 STATIC int
368 keypin_load_journal_impl(const char *data, size_t size,
369 keypin_journal_pruner_t *pruner)
370 {
371 const char *start = data, *end = data + size, *next;
372
373 int n_corrupt_lines = 0;
374 int n_entries = 0;
375 int n_duplicates = 0;
376 int n_conflicts = 0;
377
378 for (const char *cp = start; cp < end; cp = next) {
379 const char *eol = memchr(cp, '\n', end-cp);
380 const char *eos = eol ? eol : end;
381 const size_t len = eos - cp;
```
We should think about this more and make sure this is safe.Tor: unspecified