Re: [tor-bugs] #13202 [Tor]: Figure out a way to deal with bridges missing arguments.

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#13202: Figure out a way to deal with bridges missing arguments.
-------------------------+-----------------------------------------
     Reporter:  yawning  |      Owner:
         Type:  defect   |     Status:  new
     Priority:  normal   |  Milestone:
    Component:  Tor      |    Version:  Tor: unspecified
   Resolution:           |   Keywords:  bridgedb-dist, scramblesuit
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-----------------------------------------

Comment (by dcf):

 Replying to [comment:6 asn]:
 > Finally, I'm not entirely against `TOR_VERSION` because it seems like
 potentially useful information and can help us hotfix such issues in the
 future (it's also easy to implement).
 > Maybe instead of `TOR_VERSION`, we name it in a more general manner
 (like `APP_VERSION`) or something, and let other projects fill in their
 own things.

 I don't know, I still think you might come to regret such a design... Even
 if the variable is called APP_VERSION, you're going to add code to
 ScrambleSuit that says
 {{{
 app, version = parse_app_version(APP_VERSION)
 if app == "tor" and version >= 0.2.5:
     do something
 else:
     do something else
 }}}
 If any other project wants to use ScrambleSuit, and wants ScrambleSuit to
 take the "do something" branch, it will have no choice but to say "I am
 tor 0.2.5." Or else ScrambleSuit needs to have a catalog of applications
 and version numbers within it. It all starts to take some of the
 "pluggable" out of pluggable transports.

 Think about the case of pluggable transports using a proxy. Not all
 versions of tor support telling the pluggable transport to use a proxy.
 But those that do, advertise their support by setting the TOR_PT_PROXY
 variable. Pluggable transports that support the feature show that they
 support it by writing a "PROXY DONE" line. The design instead could have
 had the pluggable transport sniffing the version number to check for proxy
 support, or by declaring a new managed proxy protocol version and simply
 requiring that all pluggable transports need to support proxies. But the
 way it actually works is much nicer. It's backwards compatible and does
 what you want in every combination (including failing with an error when
 tor wants a proxy but the PT doesn't support it). Could we find a design
 like that?

 To put in in perspective, remember we once had a situation where there
 were a bunch of useless obfs3 bridges in BridgeDB because people installed
 obfsproxy but didn't open a port on their firewall. That's basically the
 same situation we're in now. With 0.2.5 only going to become more common,
 maybe this is a problem that will resolve itself.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13202#comment:7>
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