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 yawning):

 Replying to [comment:4 dcf]:
 > Replying to [comment:2 yawning]:
 > > we don't have anything like `TOR_VERSION` in the pt environment space,
 >
 > Aside, if we want other projects to use pluggable transports, we
 shouldn't add a TOR_VERSION variable.  Otherwise those other projects will
 need to lie and say they're a specific version of Tor, need to be aware of
 Tor's changelog, and need to match features with a particular Tor version.
 It's better to signal support for specific features than have them implied
 by a version number.

 This is probably true.  AFAIK we currently do not have 3rd parties using
 the pt config protocol, but it would be good to keep this in mind.
 Offtopic, I'm kicking around the idea of doing a pt protocol version 2
 with feedback from the rest of the obfuscation people (quite a few of the
 warts in the existing pt protocol could be fixed in a cleaner manner if we
 did something like this, otherwise we would need a lot of feature
 signals).

 So to sum up the current situation:
  * At a minimum, regardless of how we address this on the tor side,
 BridgeDB will need to filter out people running bridges that publish
 busted extrainfo descriptors (ScrambleSuit/obfs4 on tor 0.2.4.x), till
 affected tor versions are gone.
  * I'm not overly hopeful about contact info for the broken bridges being
 filled in (probably missing or invalid for the majority), but we should at
 least send a post to tor-relays@ highlighting this issue.
  * The ship on fixing this the right way (patching maint-0.2.4.x, yes, it
 is a bug) has sailed, so if we are going to patch tor, we need other
 options.
  * The current leading candidate for a tor side patch would be to add
 something like `TOR_PT_EXTENSIONS=smethod-args` (more to be added to the
 list as time goes on) to 0.2.5.x/0.2.6.x, and change obfsproxy/obfs4proxy
 to `SMETHOD-ERROR` if the env var is not present.  This will fix new
 deployments, but will not address people that do not upgrade tor or
 obfsproxy/obfs4proxy.  This will additionally break working configurations
 that upgrade to new obfsproxy/obfs4proxy without upgrading tor.

 Does this seem accurate to people?  I'm not particularly thrilled at the
 idea of patching 0.2.5.x/0.2.6.x for this because of the gotchas, but if
 other people think strongly that it would be a good idea, then I can start
 working on the relevant patches.

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