[tor-bugs] #32021 [Core Tor/Tor]: hs-v3: Handle rendezvous client circuit build expire properly

[Tor Bug Tracker & Wiki]

#32021: hs-v3: Handle rendezvous client circuit build expire properly
-----------------------------+---------------------------------------------
     Reporter:  dgoulet      |      Owner:  (none)
         Type:  defect       |     Status:  new
     Priority:  Medium       |  Milestone:  Tor: 0.4.3.x-final
    Component:  Core         |    Version:
  Tor/Tor                    |
     Severity:  Normal       |   Keywords:  tor-hs, tor-client, tor-circuit
Actual Points:               |  Parent ID:  #30200
       Points:  0.4          |   Reviewer:  asn
      Sponsor:               |
  Sponsor27-must             |
-----------------------------+---------------------------------------------
 This is a subtask of the bigger larger problem in #25882.

 In `circuit_expire_building()`, we have this code path:

 {{{
     if (!(TO_ORIGIN_CIRCUIT(victim)->hs_circ_has_timed_out)) {
       switch (victim->purpose) {
       case CIRCUIT_PURPOSE_C_REND_READY:
         /* We only want to spare a rend circ if it has been specified in
          * an INTRODUCE1 cell sent to a hidden service.  A circ's
          * pending_final_cpath field is non-NULL iff it is a rend circ
          * and we have tried to send an INTRODUCE1 cell specifying it.
          * Thus, if the pending_final_cpath field *is* NULL, then we
          * want to not spare it. */
         if (TO_ORIGIN_CIRCUIT(victim)->build_state &&
             TO_ORIGIN_CIRCUIT(victim)->build_state->pending_final_cpath ==
             NULL)
           break;
 }}}

 Basically, this `pending_final_cpath` is only used by v2 which means v3 is
 not handle in that case.

 And that case is: if we want to expire a rendezvous client circuit that is
 ready but has been waiting for a while on the introduction circuit as in
 its cookie has been sent in the `INTRODUCE1`, we want to spare it until
 the intro point client circuit collapses.

 Because v3 is not handled in the above, rendezvous circuit will be tagged
 as timed out with the general cutoff instead of being kept until the intro
 circuit is ready or times out. And we time out intro circuit being
 established much later than an established rendezvous circuit for which
 the `general_cutoff` will be applied on.

 Bottom line is that we need a flag within the rendezvous client circuit
 (probably hs_ident_t?) that its cookie was put in the INTRO1 cell and that
 we are waiting on the intro side signalling the
 `circuit_expire_building()` that it should wait more on that circuit.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32021>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online