[tor-dev] Towards a new version of the PT spec...

isis isis at torproject.org
Tue Sep 15 21:23:38 UTC 2015


Yawning Angel transcribed 3.3K bytes:
> So, we currently have a Pluggable Transport (PT) spec, and it kind-of
> sort-of works (The documentation is a mess that I'm working on
> cleaning up, but it's an orthogonal issue for how well it works).
> 
> There are a number of problems with the current PT spec that require
> breaking backward compatibility to fix, so eventually I would like to
> do so.
> 
> I'm soliciting input on what people would also like to see in a
> (currently hypothetical) PT spec 2.0 beyond what I already have in mind:
> 
>  MUST haves:
>   * Support dual stack Bridges correctly (Multiple server endpoints per
>     transport)

Do you mean in terms of running the same transport on say 10 IP addresses
(#7884), or just dual stack support (#11211)?

Or… both?  :)  I would really like both.  :D

>   * Increase the argument space beyond 510 bytes (Prop. #227).
>   * Mandatory ExtORPort support (currently optional, but metrics are
>     good).
>   * Centralized logging by the calling process (Probably via stderr).
>   * AF_UNIX support where sensible for better sandboxing.
> 
>  MIGHT haves:
>   * Rename the env vars to not start with "TOR_PT".  Some people claim
>     that this is a good idea (I think it is stupid and cosmetic).

It's probably a good idea to shorten it to "PT_" as asn suggested, but
removing prefixes altogether (as you obviously know) is believed to possibly
result in envvar collision (perhaps this concern has since become archaic).

>   * Ability to force at least clients to stop network activity without
>     tearing the PT down.
>   * Deprecate SOCKS4a, and make SOCKS5 mandatory for clients.

All of the above seem like good ideas to add.  I think I also agree that the
following seems out-of-scope (and likely for Apple to change the rules/APIs
out from under us).

>  UNLIKELY:
>   * Specify an interface for where fork()/exec() isn't possible (iOS).
>     I don't think this is makes sense because it is probably too
>     platform/caller specific.
>   * Allow operating both as a client and a server simultaneously.  I
>     don't see a problem with running 2 copies of something for this
>     use case.

As always, I'm glad to provide help with this stuff, whether spec or code
changes, if you want it.

-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1240 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150915/a2505e68/attachment.sig>


More information about the tor-dev mailing list