Re: [tor-bugs] #10629 [Pluggable transport]: PT spec changes for better interoperability with other projects

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

#10629: PT spec changes for better interoperability with other projects
-------------------------------------+-----------------------
     Reporter:  infinity0            |      Owner:  infinity0
         Type:  enhancement          |     Status:  assigned
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+-----------------------

Comment (by nickm):

 This is pretty excellent; it will be good to drill down into these
 requirements more.

 In my mind the biggest issue to consider here is backward compatibility:
 we want all the old PTs to keep working, and I2P probably wants to work
 with most (all?) of the old PTs, so we should make sure that any design
 decisions we make allow that.

 With that in mind...

 Replying to [ticket:10629 infinity0]:
 >> - better spec documentation
 >   - less Tor jargon, split Tor-specific information into separate
 sections (e.g. Tor env vars)

 Good idea.  In particular, we should describe which of the TOR_* variables
 are actually Tor-specific, and which are just using our namespace.

 >   - some guidelines for non-Tor programs to use PTs

 Right.

 > - possibility of letting a single process to act as both a client
 (outgoing) and server (incoming).

 That shouldn't be so hard.

 [...]
 > - better handling of per-endpoint config params, such as pubkeys
 (instead of current hack via SOCKS auth params)

 This is one of the cases where we need to think about compatibility. I2P
 would need to support the SOCKS hack already if it wants to work with any
 existing PTs that use it, and PTs will need to support the SOCKS hack in
 the future if they want to work with existing versions of Tor.

 It's okay to add a new message-passing framework, or to clean up the
 existing protocols into something cleaner, but as we do so we need to let
 old PTs continue to work, and we should make sure that we're actually
 creating less work for implementors of Tor, I2P, and PTs in the long run,
 rather than more.

 > - SSL connection with user/pass to SOCKS client; currently we assume
 cleartext

 This is possible as an extension, though IMO you should never run this on
 a remote system, so cleartext is fine.

 >   - (my own suggestion) allow unix domain sockets

 Doable.

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