distinguish PT vs proxy for real in bootstrap tracker
The bootstrap tracker work in #27167 (moved) adds distinctions (in the form of additional bootstrap phases) between connecting directly to a relay vs connecting through a proxy. It also tries to distinguish proxies from PTs.
The changes to do the distinguishing between PT vs proxy don't work, because conn->proxy_type gets set to the protocol type of the underlying protocol that tor uses to talk to the PT locally.
Activity
changed milestone to %Tor: 0.4.0.x-final
Trac:
Parent Ticket: #28018 (moved)added 040-must actualpoints::2 asn-merge component::core tor/tor milestone::Tor: 0.4.0.x-final network-team-roadmap-2019-Q1Q2 owner::catalyst parent::28018 points::2 priority::high resolution::fixed reviewer::nickm s8-bootstrap severity::normal sponsor::19 status::closed tbb-needs teor-merge tor-pt type::defect usability ux version::tor 0.4.0.1-alpha labels
Trac:
Parent: N/A to #28018 (moved)#29341 (moved) is a duplicate.
I added tbb-needs to this ticket (which I included on #29341 (moved) when I filed it).
Trac:
Keywords: N/A deleted, tbb-needs addedReplying to mcs:
I added tbb-needs to this ticket (which I included on #29341 (moved) when I filed it). Sorry for dropping the tag. Do you need this to be in 0.4.0? It might be easier to put in 0.4.1 because we can use the pubsub framework. It might be possible to put it in 0.4.0 but it might take longer, and might be too big a change at this stage of the release.
-
Replying to catalyst:
Replying to mcs:
I added tbb-needs to this ticket (which I included on #29341 (moved) when I filed it). Sorry for dropping the tag. Do you need this to be in 0.4.0? It might be easier to put in 0.4.1 because we can use the pubsub framework. It might be possible to put it in 0.4.0 but it might take longer, and might be too big a change at this stage of the release.
I added Georg to the Cc list on this ticket.
I looked at the Core Tor release dates on the following page: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases
The misleading bootstrap messages are confusing, but I think that is acceptable in a Tor Browser alpha. However, this seems like a bug we would not want to have in a stable release (at least not for a long period of time).
Georg can comment more accurately than I can, but we might ship tor 0.4.0 with Tor Browser 8.5 since the browser release date will be very close to the 0.4.0 stable date. That means that our users will have to live with this bug for 4 months or longer. Maybe that is okay because experts who are called upon to help troubleshoot bootstrap problems can be told about this bug, and most users probably do not use a local proxy (in which case one can assume that "proxy" must mean "pluggable transport"). As far as I know, we don't have any hard data about local proxy use though.
Trac:
Cc: brade, mcs to brade, mcs, gk 
Replying to mcs:
Replying to catalyst:
Replying to mcs:
I added tbb-needs to this ticket (which I included on #29341 (moved) when I filed it). Sorry for dropping the tag. Do you need this to be in 0.4.0? It might be easier to put in 0.4.1 because we can use the pubsub framework. It might be possible to put it in 0.4.0 but it might take longer, and might be too big a change at this stage of the release.
I added Georg to the Cc list on this ticket.
I looked at the Core Tor release dates on the following page: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases
The misleading bootstrap messages are confusing, but I think that is acceptable in a Tor Browser alpha. However, this seems like a bug we would not want to have in a stable release (at least not for a long period of time).
I agree.
Georg can comment more accurately than I can, but we might ship tor 0.4.0 with Tor Browser 8.5 since the browser release date will be very close to the 0.4.0 stable date. That means that our users will have to live with this bug for 4 months or longer. Maybe that is okay because experts who are called upon to help troubleshoot bootstrap problems can be told about this bug, and most users probably do not use a local proxy (in which case one can assume that "proxy" must mean "pluggable transport"). As far as I know, we don't have any hard data about local proxy use though.
While 0.4.x probably won't make it into Tor Browser 8.5 it's very likely that one of the point releases could pick up 0.4.x. So, yes, this is unfortunate. I am inclined to agree that this bug is not a hard blocker for you for 0.4.0, though. If we feel strongly at some point we can just stay on 0.3.5.x at least until the bug is fixed in a later stable release.
WIP branch at https://github.com/tlyu/tor/tree/bug28925 , needs a bit of cleanup and some documentation.
Not the greatest strategy (adds more state into
or_connection_t), but not too horrible either.Manually tested with built-in PT bridges on TB 8.5a8; haven't yet tested non-PT proxies.
Pull request at https://github.com/torproject/tor/pull/827
I believe this merges cleanly to master, but it pushes a couple of files over their line count exceptions in practracker. I'm not sure how we want to handle that.
Trac:
Status: assigned to needs_reviewOpened #29876 (moved) for a possible related issue that I discovered while working on this ticket.
Squashed as bug28925_040_squashed at https://github.com/torproject/tor/pull/836 Master merge is bug28925_master_squashed at https://github.com/torproject/tor/pull/837
I've read the code comments and warnings from practracker. I think I need to update the practracker exceptions file in a separate commit.
I've updated the merge policy to include a "wait for master and practracker" step: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/MergePolicy?action=diff&version=9
Longer-term, we should think about how to improve the ergonomics of practracker:
- If we push and build master first, then we'll catch practracker errors early, see #29879 (moved).
- If we write a script to update exceptions and merge forward, then we'll be able to handle exceptions in backport branches faster and more reliably, see #29880 (moved). We don't need to make this change until we split off an 0.4.2 branch.
But I'm not sure how to discover practracker errors in backport branches. We could require master merges for every backport branch. I wonder if there is a way to automate that? I opened #29881 (moved) to see if we could make a bot.
I tried rebuilding the file, but the diff was a mess: https://github.com/torproject/tor/pull/837/commits/973451edd1a8f0fe7c07ae5ba7fe8256ef279f95
I think practracker is using OS file order (or maybe an order based on python minor versions?), but we really want a stable file and function order. See #29882 (moved).
I also wonder if we should replace the practracker list with every new release, so that we don't keep old exceptions. See #29883 (moved).
So I guess that I'm meant to manually edit the file by finding any modified exceptions and updating them? There has to be an easier way. (Maybe #29880 (moved)?) And if there isn't, it should be documented in the warning message, and at the start of the script. See #29884 (moved).
mentioned in issue #29341 (moved)
mentioned in issue #29341 (moved)
mentioned in issue #29876 (moved)
moved to tpo/core/tor#28925 (closed)
mentioned in issue tpo/core/tor#29876 (closed)
