consider reordering PT/proxy phases

A pluggable transport can itself use a firewall-bypass proxy, so maybe the progression should go more like

1. conn_pt
2. conn_proxy
3. conn_proxy_done
4. conn_pt_done

changed milestone to %Tor: unspecified

added 040-deferred-20190220 actualpoints::8.5 bootstrap component::core tor/tor ex-28018-child ex-sponsor-19 ex-sponsor19 milestone::Tor: unspecified network-team-roadmap-2020Q1 owner::ahf points::3 priority::medium proxy pt reviewer::catalyst severity::normal sponsor::28-can status::needs-revision type::enhancement labels

Trac:
Sponsor: Sponsor8 to Sponsor19

Trac:
Owner: catalyst to ahf

Deferring 51 tickets from 0.4.0.x-final. Tagging them with 040-deferred-20190220 for visibility. These are the tickets that did not get 040-must, 040-can, or tor-ci.

Trac:
Keywords: N/A deleted, 040-deferred-20190220 added
Milestone: Tor: 0.4.0.x-final to Tor: unspecified

Trac:
Points: N/A to 3

The change would be to reorder the phases so the proxy phases are "inside" the PT phases. Last I checked, tor doesn't know about whether or not the PT client itself uses a proxy, so the PT would have to explicitly tell tor.

We can do the reordering now, or wait until we have a PT client interface that can report intermediate progress when using a PT tunneled through a proxy. ahf, which do you think is better?

There might be reasons to have these phases in any number of slightly different orderings, including the current ordering. I would have to refresh my memory about the current behavior to be sure.

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

Trac:
Keywords: N/A deleted, ex-sponsor-19 added

Trac:
Sponsor: Sponsor19 to N/A
Keywords: sponsor19-also, s8-bootstrap deleted, N/A added

Trac:
Keywords: N/A deleted, network-team-roadmap-2019-Q1Q2 added

Unparent remaining open children of #28018 (moved).

Trac:
Keywords: N/A deleted, bootstrap, ex-sponsor19, ex-28018-child added
Parent: #28018 (moved) to N/A

Moving this to needs review.

PR in https://github.com/torproject/tor/pull/1151

Trac:
Status: assigned to needs_review
Actualpoints: N/A to 8.5

Trac:
Reviewer: N/A to catalyst

Replying to ahf:

Moving this to needs review.

PR in https://github.com/torproject/tor/pull/1151 Thanks!

The stuff to explicitly note whether we're using a PT looks good. I haven't done manual testing of it yet.

I think when we talked about this on IRC we agreed to have separate new phases for "PT client is connecting/connected to its proxy"?

(Summary -- control-spec.txt already is overly specific and refers to the TCP connection to the PT proxy. So my proposed reordering turns out to be wrong. I think having more specific new bootstrap phases also makes troubleshooting easier.)

For the reviewer: Should we change the tests in test_controller_events to instead of storing a single string each time we have a bootstrap event, that we instead append to a list and then check if the list is correct after all the state transitions have happened?

Yes, I think there might places in the unit tests where that would be helpful. Or maybe make the entire "make a state change and assert an expected bootstrap message" a macro?

Trac:
Status: needs_review to needs_revision

Trac:
Sponsor: N/A to Sponsor28-can

Adding sponsor tickets from old roadmap into new one.

Trac:
Keywords: N/A deleted, network-team-roadmap-2020Q1 added

Move tickets to new roadmap.

Trac:
Keywords: network-team-roadmap-2019-Q1Q2 deleted, N/A added

changed time estimate to 24h

added 68h of time spent

moved to tpo/core/tor#28930 (closed)