[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:32:27 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: |
-----------------------------+-----------------------
Description changed by infinity0:
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.
>
> 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.
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 to make outgoing connections,
e.g. if one users wants to run his own instance. two options here:
- SSL connection with user/pass to the SOCKS transport client
- use unix domain sockets. This also frees up ports, which is extra-
useful in PT composition. Doesn't work on windows, though.
--
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10629#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list