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

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Jan 27 16:30:50 UTC 2014


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

Old description:

> I spoke with the i2p guys today and here are some of their suggestions
> for the PT spec. These would make it easier for them (and future other
> projects) to use Tor's PTs.
>
> - better spec documentation
>   - less Tor jargon, split Tor-specific information into separate
> sections (e.g. Tor env vars)
>   - some guidelines for non-Tor programs to use PTs
> - possibility of letting a single process to act as both a client
> (outgoing) and server (incoming).
> - flashproxy must allow client-specific remote endpoints (already as
> #10196)
> - better handling of per-endpoint config params, such as pubkeys (instead
> of current hack via SOCKS auth params)
> - SSL connection with user/pass to SOCKS client; currently we assume
> cleartext
>   - (my own suggestion) allow unix domain sockets
>
> related: #7153

New description:

 I spoke with the i2p guys today and here are some of their suggestions for
 the PT spec. These would make it easier for them (and future other
 projects) to use Tor's PTs.

 Major improvements:

 - better spec documentation
   - less Tor jargon, split Tor-specific information into separate sections
 (e.g. Tor env vars)
   - some guidelines for non-Tor programs to use PTs
 - better handling of per-endpoint config params such as pubkeys, instead
 of current hack via SOCKS auth params

 Smaller enhancements, "good to have":

 - possibility of letting a single process to act as both a client
 (outgoing) and server (incoming).
 - flashproxy must allow client-specific remote endpoints (already as
 #10196)
 - don't trust the entire localhost machine, e.g. if one users wants to run
 his own instance. two options here:
   - SSL connection with user/pass to SOCKS client
   - use unix domain sockets. This also frees up ports, which is extra-
 useful in PT composition.

--

Comment (by infinity0):

 Restructured the description to make it clear which ones are important vs
 optional.

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


More information about the tor-bugs mailing list