Opened 9 months ago

Last modified 2 months ago

#23493 new defect

IPv6 v3 Single Onion Services fail with a bug warning

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop224, tor-hs, single-onion, ipv6, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points: 0.7
Parent ID: Points: 1
Reviewer: Sponsor:

Description

Using the latest tor master (3092c8bb3e) and the latest chutney (d3cec81):

chutney/tools/test-network.sh --flavour single-onion-v3-ipv6

Fails and logs a bug message:

Sep 13 12:21:43.845 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 13 12:21:43.845 [notice] Bootstrapped 100%: Done
Sep 13 12:21:44.798 [info] set_rotation_time: Next descriptor rotation time set to 2017-09-13 12:24:00 for ya3etbnz4ncqaexjurfbtozzp5puva3uzw2apbaatfvvpsvyzq7iikid
Sep 13 12:21:44.802 [info] build_descriptors_for_new_service: Hidden service ya3etbnz4ncqaexjurfbtozzp5puva3uzw2apbaatfvvpsvyzq7iikid has just started. Both descriptors built. Now scheduled for upload.
Sep 13 12:21:44.803 [info] extend_info_from_node: Including Ed25519 ID for $DB859DF7648323E1766C122E077DA476720A0FB0~test000a at 127.0.0.1
Sep 13 12:21:44.803 [warn] tor_bug_occurred_: Bug: src/or/hs_service.c:403: service_intro_point_new: Non-fatal assertion !(!ls) failed. (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug: Non-fatal assertion !(!ls) failed in service_intro_point_new at src/or/hs_service.c:403. Stack trace: (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug:     0   tor                                 0x000000010d938989 log_backtrace + 73 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug:     1   tor                                 0x000000010d9a6614 tor_bug_occurred_ + 452 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug:     2   tor                                 0x000000010d74b671 hs_service_run_scheduled_events + 12817 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.805 [warn] Bug:     3   tor                                 0x000000010d7754fe hs_service_callback + 62 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug:     4   tor                                 0x000000010d7f024f periodic_event_dispatch + 271 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug:     5   libevent-2.1.6.dylib                0x000000010e4a90bf event_process_active_single_queue + 371 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug:     6   libevent-2.1.6.dylib                0x000000010e4a6699 event_base_loop + 1170 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug:     7   tor                                 0x000000010d765696 do_main_loop + 2422 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug:     8   tor                                 0x000000010d76e432 tor_main + 546 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug:     9   tor                                 0x000000010d4236eb main + 27 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [warn] Bug:     10  libdyld.dylib                       0x00007fff8edaf235 start + 1 (on Tor 0.3.2.0-alpha-dev 3092c8bb3e5eef94)
Sep 13 12:21:44.806 [info] pick_needed_intro_points: Unable to find a suitable node to be an introduction point for service ya3etbnz4ncqaexjurfbtozzp5puva3uzw2apbaatfvvpsvyzq7iikid.

Child Tickets

TicketStatusOwnerSummaryComponent
#23502newdgouletprop224: Don't make IPv4 mandatory because one day we'll have IPv6 only relaysCore Tor/Tor
#23507accepteddgouletAdd single onion unreachable address algorithm to prop224Core Tor/Tor
#23576assigneddgouletMake service_intro_point_new() take a node instead of an extend_infoCore Tor/Tor
#23577closedAdd rendezvous point IPv6 address to client introduce cellsCore Tor/Tor
#23588assignedneelWrite fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()Core Tor/Tor
#23740closedprop224: tor_bug_occurred_(): Bug: src/or/hs_service.c:403: service_intro_point_new: Non-fatal assertion !(!ls) failed. (on Tor 0.3.2.1-alpha 290274dbb5428bc5)Core Tor/Tor
#23759assigneddgouletRefactor common code out of setup_introduce1_data and intro point functionsCore Tor/Tor
#23818newMake v3 single onion services retry failed connections with a 3-hop pathCore Tor/Tor
#23820closedteorMake sure v3 single onion services and v3 onion service clients only send IPv4 addressesCore Tor/Tor
#24002closeddgouletCheck for ed25519 key is inverted in pick_intro_point()Core Tor/Tor
#24181accepteddgouletPut IPv6 and unrecognised link specifiers in onion service EXTEND cellsCore Tor/Tor
#24182assigneddgouletPad INTRODUCE cells to hide the number of link specifiersCore Tor/Tor
#24193accepteddgouletMake v3 single onion services parse and use IPv6 introduce link specifiersCore Tor/Tor
#24868assignedteorCheck a consensus parameter before activating onion service IPv6 featuresCore Tor/Tor

Change History (26)

comment:1 Changed 9 months ago by teor

Priority: HighMedium

comment:2 Changed 9 months ago by dgoulet

Status: newneeds_information

Oh dear... hmmm proposal 224 makes IPv4 *mandatory* in order to extend to the relay and seems in this case you have IPv6 only?...

Is this something we want to allow right now or should I say simply possible to have NO IPv4 for a relay?

comment:3 Changed 9 months ago by dgoulet

About the above, see #23502 ... so until the patch is in, that test will unfortunately fail.

comment:4 in reply to:  2 ; Changed 9 months ago by teor

Status: needs_informationnew

Replying to dgoulet:

Oh dear... hmmm proposal 224 makes IPv4 *mandatory* in order to extend to the relay and seems in this case you have IPv6 only?...

The single onion service in this test can only make IPv6 connections.
This works for v2, but not v3.

Is this something we want to allow right now or should I say simply possible to have NO IPv4 for a relay?

We can make IPv6 work with single-hop client and service connections to intro and rend points. It works for v2 single onion services. We talked about it for v3, but it never made it into the prop224 spec.

Edit: I opened #23507 with a list of steps we can add to the spec. We should implement them in this ticket!

I don't see how #23502 is a dependency. Initiating clients/services should always include IPv4 and IPv6, even if they wouldn't use them (step 0). And responding clients/services should use a direct connection if available, or a 3-hop connection if not (steps 1 & 2).

Last edited 9 months ago by teor (previous) (diff)

comment:5 in reply to:  4 ; Changed 9 months ago by dgoulet

Replying to teor:

Replying to dgoulet:

Oh dear... hmmm proposal 224 makes IPv4 *mandatory* in order to extend to the relay and seems in this case you have IPv6 only?...

The single onion service in this test can only make IPv6 connections.
This works for v2, but not v3.

Is this something we want to allow right now or should I say simply possible to have NO IPv4 for a relay?

We can make IPv6 work with single-hop client and service connections to intro and rend points. It works for v2 single onion services. We talked about it for v3, but it never made it into the prop224 spec.

Yeah, it will make it with #23502. Spec and code change for that matter. Basically, any link specifiers for the IP (in descriptor) and RP (in INTRO cell) were requiring an IPv4 else you couldn't use the relay.

Edit: I opened #23507 with a list of steps we can add to the spec. We should implement them in this ticket!

I don't see how #23502 is a dependency. Initiating clients/services should always include IPv4 and IPv6, even if they wouldn't use them (step 0). And responding clients/services should use a direct connection if available, or a 3-hop connection if not (steps 1 & 2).

In this scenario, no IPv4 were available with this chutney test so the code was just saying "nope" and you wouldn't pass step 0 which is what #23502 is addressing.

Then considering the above fixed, you are right that if the chosen IP can't be reached via a direct connection, we fallback to 3-hop, see pick_intro_point(). However, for the RP, I'm not sure there is a fallback, even for v2... See pick_rendezvous_node(), that fallback concept is only if ENABLE_TOR2WEB_MODE.

The second thing here that I want to raise is that including both IPv4 and IPv6 is *not* possible right now within tor and the reason is that from a node_t, we create an extend_info_t object used for opening a circuit and that object can only take one type of address, v4 or v6 (tor_addr_t addr). Furthermore, the extend_cell_format() simply doesn't care at all about IPv6. (#22810 is probably relevant and should be expanded to IPv6 also).

So, IPv6 can only be used in a direct connection really and is entirely ignored for 3-hop.

If you can confirm the above, we should open tickets about all that.

comment:6 in reply to:  5 Changed 9 months ago by teor

Replying to dgoulet:

Replying to teor:

Replying to dgoulet:

Oh dear... hmmm proposal 224 makes IPv4 *mandatory* in order to extend to the relay and seems in this case you have IPv6 only?...

The single onion service in this test can only make IPv6 connections.
This works for v2, but not v3.

Is this something we want to allow right now or should I say simply possible to have NO IPv4 for a relay?

We can make IPv6 work with single-hop client and service connections to intro and rend points. It works for v2 single onion services. We talked about it for v3, but it never made it into the prop224 spec.

Yeah, it will make it with #23502. Spec and code change for that matter. Basically, any link specifiers for the IP (in descriptor) and RP (in INTRO cell) were requiring an IPv4 else you couldn't use the relay.

But this is fine at the moment.

All relays have an IPv4 address, so clients and services can put them in the link specifiers in the descriptor and introduce cell.

Edit: I opened #23507 with a list of steps we can add to the spec. We should implement them in this ticket!

I don't see how #23502 is a dependency. Initiating clients/services should always include IPv4 and IPv6, even if they wouldn't use them (step 0). And responding clients/services should use a direct connection if available, or a 3-hop connection if not (steps 1 & 2).

In this scenario, no IPv4 were available with this chutney test

I don't understand what you mean here.

The service connects over IPv6, but it has a consensus with an IPv4 address, why isn't it using it in the link specifier for the intro point in the descriptor?

so the code was just saying "nope" and you wouldn't pass step 0 which is what #23502 is addressing.

Then considering the above fixed, you are right that if the chosen IP can't be reached via a direct connection, we fallback to 3-hop, see pick_intro_point(). However, for the RP, I'm not sure there is a fallback, even for v2... See pick_rendezvous_node(), that fallback concept is only if ENABLE_TOR2WEB_MODE.

That's ok, it's only needed in Tor2web mode: all other clients connect using a 3-hop path through a guard or bridge they can reach.

The second thing here that I want to raise is that including both IPv4 and IPv6 is *not* possible right now within tor and the reason is that from a node_t, we create an extend_info_t object used for opening a circuit and that object can only take one type of address, v4 or v6 (tor_addr_t addr). Furthermore, the extend_cell_format() simply doesn't care at all about IPv6. (#22810 is probably relevant and should be expanded to IPv6 also).

Sending an EXTEND with IPv4 is ok at the moment, but it will need to change for relays to extend to IPv6 (for example, IPv6 ORPort self-checks). I think there is a ticket for this already.

So, IPv6 can only be used in a direct connection really and is entirely ignored for 3-hop.

Yes, at the moment.

If you can confirm the above, we should open tickets about all that.

Some already have tickets.

comment:7 Changed 9 months ago by dgoulet

Owner: set to dgoulet
Status: newaccepted

comment:8 Changed 9 months ago by teor

Ok, so I've opened some tickets for the things we need to fix.
I don't think we want 0.3.2 failing with a bug warning on v3 single onion services on IPv6.

So we either need to get #23502 working, or disable that combination of config options, and the chutney test.

comment:9 Changed 9 months ago by teor

This comments section got complicated, so I'm going to summarise the issues in 0.3.2.1-alpha, my suggested changes in my bug23493 branch, and what we should fix in 0.3.3.

My branch bug23493 completes the implementation of the single onion service reachability algorithm in #23507. This is the minimum we need to do for functional single onion services with ReachableAddresses/ClientUseIPv6 in 0.3.2. (The alternative is to rip out some of the existing implementation, which I think is worse.)

This is how v3 single onion services will work after we merge this branch:

  • services choose intro points they can reach, if possible (0.3.2.1-alpha)
    • if not, they choose any valid intro point (0.3.2.1-alpha)
  • services connect to intro points directly, if possible (0.3.2.1-alpha)
    • if not, they fail to connect, or try to connect to an unreachable address (0.3.2.1-alpha)
    • if not, they connect over a 3-hop path (bug23493)
  • services put IPv4 addresses for those intro points in the descriptor (bug23493)
  • clients choose rend points (0.3.2.1-alpha)
    • clients know about single onion services from the descriptor, but they don't do anything different for them, and they don't need to (0.3.2.1-alpha)
  • clients put rend point IPv4 addresses in the INTRODUCE cell (0.3.2.1-alpha)
  • services choose a reachable rend address from the INTRODUCE cell, if possible (0.3.2.1-alpha)
    • if not, they fail to connect, or try to connect to an unreachable address (0.3.2.1-alpha)
    • if not, they connect over a 3-hop path (bug23493)

This is what we'll change in 0.3.3 for v3 onion services:

  • services put IPv4 and IPv6 addresses for their intro points in the descriptor (#23576)
  • clients put rend point IPv4 and IPv6 addresses in the INTRODUCE cell (#23577, #23589)
  • single onion services choose rend via direct IPv6, when IPv6 is reachable and isn't preferred, but IPv4 is unreachable (#23588)
    • in 0.3.2.1-alpha, they fail in this rare case, which can only be triggered by 0.3.3 clients with fixes for #23577 and #23589
    • in bug23493, they use a 3-hop path in this rare case, which can only be triggered by 0.3.3 clients with fixes for #23577 and #23589

I've deferred all the other child tickets to 0.3.3.

Edit: sometimes single onion services try to connect to an unreachable address

Last edited 9 months ago by teor (previous) (diff)

comment:10 Changed 9 months ago by teor

Owner: changed from dgoulet to teor
Status: acceptedassigned

comment:11 Changed 9 months ago by teor

Status: assignedneeds_review

comment:12 Changed 9 months ago by teor

Actual Points: 0.5

comment:13 Changed 9 months ago by asn

Here is a short review:

  • Not a big fan of poking into the guts of service with service->config.is_single_onion to figure out if SoS or not. I suggest now that we are more serious about this feature to use a function like int service_is_single_onion(hs_service_t *).
  • direct_conn_inout is a weird variable name. Why inout and not out? Also let's improve variable naming so that this BUG makes a bit more sense if (BUG(direct_conn && direct_conn_inout && !*direct_conn_inout)) {.
  • 7c3ba98cd is a bit sketch. I wonder how come that was not needed before. If it was not needed, is it just defense-in-depth? Can we add a non-fatal assert to make sure it never triggers? Also, is extend_info_is_a_configured_bridge() the right thing to do? What happens if the bridge has a PT on a different address than the bridge?
  • It's kinda scary that there is no unittests for any of the SoS HSv3 logic.

comment:14 Changed 9 months ago by nickm

Status: needs_reviewneeds_revision

Additional minor notes:

  • The log message "Launching a %s circuit" will say "launching a anonymous circuit" when "an anonymous circuit" would be correct.
  • Looks like "make check-spaces" will fail.

for asn:

  • "inout" is a convention for "'in and out': the value pointer is both read and written." Not sure if that answers your "why not out" naming question?

comment:15 in reply to:  14 Changed 9 months ago by teor

Actual Points: 0.50.7
Status: needs_revisionneeds_review

I've updated my bug23493 branch.

Replying to asn:

Here is a short review:

  • Not a big fan of poking into the guts of service with service->config.is_single_onion to figure out if SoS or not. I suggest now that we are more serious about this feature to use a function like int service_is_single_onion(hs_service_t *).

I was always serious about this feature :-)

And I agree, it's important to have a read-only accessor when we are passing inout references to a copy of that flag.

See commit 76d25b0b74.

That said, the existing code doesn't have accessors for any of the other flags in config, so it's up to you if you want this flag to be different.

  • direct_conn_inout is a weird variable name. Why inout and not out? Also let's improve variable naming so that this BUG makes a bit more sense if (BUG(direct_conn && direct_conn_inout && !*direct_conn_inout)) {.

I rewrote the function comment and made the variable naming clearer in fixup b51005940d.

  • 7c3ba98cd is a bit sketch. I wonder how come that was not needed before.

It's needed to make sure that we don't connect to an address that's banned by ReachableAddresses, ClientUseIPv4/6, or similar options, which have been around for a long time. In previous releases, we trusted calling code to do the right thing.

If it was not needed, is it just defense-in-depth?

Yes, it's defense in depth.

Can we add a non-fatal assert to make sure it never triggers?

We could, but I think a BUG() condition is the right way to go here - it allows us to log the error, and respond correctly by refusing to connect to the address.

I also added a comment that explains the change in fixup commit 79875f084b.

Also, is extend_info_is_a_configured_bridge() the right thing to do? What happens if the bridge has a PT on a different address than the bridge?

!extend_info_is_a_configured_bridge() is the right thing to do, because bridges with PTs routinely lie about their addresses, and bridges without PTs have always been allowed to connect to their configured addresses. PT reachable addresses aren't controlled by tor, and are apparently out of scope for PT 2.0, too.

  • It's kinda scary that there is no unittests for any of the SoS HSv3 logic.

I agree, but I don't have any time to write any this week. Can we open a separate ticket for this in 0.3.2?

Replying to nickm:

Additional minor notes:

  • The log message "Launching a %s circuit" will say "launching a anonymous circuit" when "an anonymous circuit" would be correct.

Fixup 898495e6bd.

  • Looks like "make check-spaces" will fail.

Oops. I had that in my workflow, but it dropped out.

Fixup 15bc97ee7d.

comment:16 Changed 9 months ago by asn

Status: needs_reviewneeds_revision

Sorry for the slow responses here. We've been very busy with testing and bugfixing. Here are some thoughts:

My main concerns with the current patch is that it's a bit brutal. Ideally, I'd like SoS to be a beautiful feature with a well designed interface and very specific call-sites around the codebase. I don't think that's the case currently. I'm afraid that we started developing the prop224 SoS feature too late in 0.3.2 and we don't have enough time to make it nice and well-tested. I personally take the blame here as well, since we added the SoS feature in the first place, when IMO we should have waited till we have the time to actually design it properly.

Anyhow, right now I mainly dislike the hs_get_extend_info_from_lspecs() changes and the fact that we have no tests for the new features/bugfixes:

  • I really don't like the patch to hs_get_extend_info_from_lspecs(). It's already a hard to digest function, and it becomes even harder. I have trouble even understanding the function documentation, with so many cases and IPv6 interactions with the SoS feature.
  • Furthermore, on hs_get_extend_info_from_lspecs() I don't like any of the added direct_conn stuff. direct_conn_inout is a variable that carries a value and also gets overwritten by the func? That's a new interface for Tor I think and it seems like a bad idea. Especially since it gets used and written all over the function.

Ideally I'd like 2-3 SoS-specific functions that do SoS-specific stuff only when needed and they are clearly labeled as such. I don't want any direct_conn stuff casually laying around the codebase.

  • Case in point:
    +
    +      if (ei == NULL && direct_conn) {
    +        /* Try again as an indirect connection */
    +        direct_conn = 0;
    +        ei = get_extend_info_from_intro_point(ip, direct_conn);
    +      }
    +
           if (ei == NULL) {
    -        if (!direct_conn) {
             /* In case of a multi-hop connection, it should never happen that we
              * can't get the extend info from the node. Avoid connection and
              * remove intro point from descriptor in order to recover from this
              * potential bug. */
             tor_assert_nonfatal(ei);
    -        }
    

The block of code added is quite confusing to someone who is not an expert with the SoS feature. IMO, the "retry with 3-hops" SoS logic should be well-documented and abstracted in an SoS-function and not just a Try again as an indirect connection comment in the middle of that func.

Also, why was the if (!direct_conn) block removed, but not the comment? Are we sure it's a multi-hop connection at that point? If yes, let's add an assert or sth.

I'm not sure what to suggest here, since fixing the interface issues above and writing unittests is not an easy task.

Here are a few options:

a) We merge teor's patch now and hope that nothing breaks (ideally with some improvements to the issues above). We then address the added technical debt in 0.3.3 with a proper refactoring of the SoS feature.

b) We don't merge teor's patch right now , and keep things simple with less code added during the bugfix period. We also add a log message when SoS+prop224 is enabled to say that this feature is super experimental.

c) We rip out SoS entirely from prop224 codebase, and implement it properly in 0.3.3 .

I'm personally leaning towards (a) right now, especially if teor helps us address the technical issues pointed out above, and with maintaining/debugging the added features. Otherwise we could go with the (b) or (c) direction.

comment:17 Changed 9 months ago by dgoulet

Thanks for this comment asn and your great work teor.

I do share these concerns as well. I'll also take blame here on adding half of a SoS feature while we were re-writing the entire HS subsystem, we shouldn't have done that as we see now that it is much more complicated in terms of interface, algorithm and integration.

I've been silent in the last week about this because I've been thinking about it on what is best. My initial idea was to sit down at the Montreal meeting and discuss what would be best to go forward.

I propose we do that in any case but in the meantime, I'm slightly tempted to actually go with (c) here so we do not go in the direction of accumulating technical debt that we are unhappy with in the hope of refactoring in a later version. It usually doesn't work that smoothly... The only thing we must be sure of is for a 032 client to be able to reach a SoS which it should by design because it doesn't behave differently in the case of a SoS or non-SoS service in theory.

Then, in 033 we introduce the service functionality in a clean well discussed interface and for which we all agree about how to proceed with a SoS. The number of conditions to switch from one hop to 3 hop or v4 vs v6 is not that simple, we should nail it down in a spec or doc before we do anything more. Sprinkling direct_conn in many places of the code honestly worries me and I would like us to take a step back and sit down together so we can all be on the same page.

comment:18 Changed 9 months ago by teor

Thanks for these reviews, I won't be able to do any revisions for about a week.
Let's work through it in Montreal.

comment:19 Changed 8 months ago by teor

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

We will add v3 single onion IPv6-only support in a later release, none of our users need this right now, and if they want it, they should use v3 hidden services (with IPv6 bridges or ClientUseIPv4 0).

comment:20 Changed 8 months ago by teor

Status: needs_revisionnew

My branch bug23820_032 is a bugfix for 0.3.2 for this issue. It stops IPv6-only v3 single onion services from being configured, and makes them fail at rendezvous with a warningif someone manages to configure them.

But we still need to fix this properly for 0.3.3.

comment:21 Changed 6 months ago by teor

Owner: teor deleted
Status: newassigned

Disowning this ticket, because I won't be able to do it in 0.3.3.

We have to do these tasks in a particular order to minimise information leaks:

  • IPv6 single onion services
  • IPv6 relay extends
  • IPv6 relay reachability (provides cover traffic for IPv6 client extends)
  • IPv6 client extends for exit circuits
  • IPv6 client extends for multi-hop onion service circuits

comment:22 Changed 6 months ago by teor

Status: assignednew

Mark all tickets that are assigned to nobody as "new".

comment:23 Changed 5 months ago by dgoulet

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

Moving a bunch of tickets from 033 to 034.

comment:24 Changed 3 months ago by nickm

Keywords: 034-triage-20180328 added

comment:25 Changed 3 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:26 Changed 2 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Note: See TracTickets for help on using tickets.