[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #27849 [Core Tor/Tor]: Bootstrapping hangs with 'SocksPort 0'



#27849: Bootstrapping hangs with 'SocksPort 0'
----------------------------------------------+----------------------------
 Reporter:  pabs                              |          Owner:  (none)
     Type:  defect                            |         Status:  new
 Priority:  Very High                         |      Milestone:  Tor:
                                              |  0.3.5.x-final
Component:  Core Tor/Tor                      |        Version:  Tor:
                                              |  0.3.4.8
 Severity:  Normal                            |     Resolution:
 Keywords:  config, regression, backport-034  |  Actual Points:
Parent ID:                                    |         Points:
 Reviewer:                                    |        Sponsor:
                                              |  Sponsor8-can
----------------------------------------------+----------------------------

Comment (by dgoulet):

 Replying to [comment:12 arma]:
 > I was going to agree with pabs that the right fix is that roles should
 look at Tor's config, and if somebody does an add_onion then Tor's config
 changed, so the role changed ("now we're an onion service role").

 FYI, in theory, `ADD_ONION` should add the "HS" role to your tor and thus
 enable the `hs_service` callback from the mainloop and in turn enable all
 other callbacks needed to properly run tor. If an `ADD_ONION` command
 failed to bootstrap tor, we have another problem. I'll investigate.

 > But then I realized there are controller commands like "resolve" that
 expect to be able to use the network. They aren't changing Tor's config or
 role, they're just trying to *use* Tor.

 Yes, considering the amount of things we can do through the control port,
 it gets complicated quickly to select which one can enable things or not.

 >
 > Also, every role (onion service, relay, client, directory authority,
 etc) starts by bootstrapping directory information and launching client
 circuits to make sure things are working. So putting that as part of "ALL"
 makes a lot of sense.
 >
 > In fact, I think there's a good argument for having us do "the basics"
 as dgoulet called them even when there's no controlport -- first because
 there might be some other exception that we didn't think of that will bite
 us here again, and second because a person who configures their Tor this
 way probably expects it to bootstrap (and also now it'll be closer to
 ready for whatever they ask it to do next). If we think it's a stupid
 config that nobody should use, we should refuse to start with it, not let
 it run but then have it do surprising things.

 Agree. I'm currently aiming at considering the ControlPort set to be part
 of enabling all basic roles since one can almost do most of the roles
 through that port...

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27849#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs