[tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon May 15 07:57:21 UTC 2017


#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
------------------------------+------------------------------------
 Reporter:  karsten           |          Owner:
     Type:  enhancement       |         Status:  needs_revision
 Priority:  Medium            |      Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor      |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:                    |         Points:  .2 remaining
 Reviewer:  nickm             |        Sponsor:
------------------------------+------------------------------------

Comment (by arma):

 Looks like we're trying to make this ticket more complicated than it is.

 The {{{feature18329}}} branch is almost entirely about the new torrc
 option, so yes, it is all user-facing. I think we should stick with words,
 like "none", "email", "https", which makes it easily extensible to more
 values, without messing with Tor at all, if the future brings us new
 distribution strategies.

 (If we used numbers instead, we would need to let the user configure a
 number that this Tor version doesn't know about, so people can choose
 other distribution approaches later. But then you'd need to keep everybody
 synchronized on what the numbers mean, and people could still list numbers
 that you haven't picked a definition for yet. tl;dr, I don't think it
 would solve much to use numbers, and I think it would indeed hurt the
 usability.)

 The BridgeDB behavior can be very simple: if the field is there and
 bridgedb recognizes the value in the field, do the right thing with it,
 else if the field is there and bridgedb doesn't recognize it, don't
 distribute that bridge.

 I agree with Damian that we could be a bit clearer on the torspec side. I
 think what dgoulet was going for was the same spec as the Contact field
 has. From Tor's perspective, it is essentially an "anything goes" string.
 We could change it to say "set of 'key and optional value' fields" or
 something if we liked, but I think the only effect of trying to constrain
 it here will be producing bugs in stem later if we decide to change it.
 Damian, what would you like to see the spec for the Contact field look
 like? Then we can use that here too.

 Nick, what did you mean by "with Tor restricted to only accept recognized
 names if they appear in torrc"? You're hoping that we teach Tor more about
 the possible values of the field, and that it says something like "nope,
 never heard of that one, you can't set it" for ones it doesn't know about?
 Does that mean that people running Tor on (say) version 0.3.1.x will need
 to upgrade in order to list a name that we started using while (say) Tor
 0.3.2.x was current? Why would we do that?

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


More information about the tor-bugs mailing list