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

George Kadianakis desnacked at riseup.net
Mon Sep 7 23:38:41 UTC 2015


Yawning Angel <yawning at schwanenlied.me> writes:

> 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)
>   * 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).

I feel OK with renaming env vars to start with "PT" instead of "TOR_PT", if that
will make the spec more welcoming to third-party projects

>   * Ability to force at least clients to stop network activity without
>     tearing the PT down.
>   * Deprecate SOCKS4a, and make SOCKS5 mandatory for clients.
>
>  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.
>
> I probably missed some things.  If people have strong opinions about
> this, do reply, otherwise I *will* design something that I like, which
> will not include what other people want.
>

Hm. I think another feature that the PT land really wanted in the past was to be
able to rate limit pluggable transports. I guess people would still appreciate
this.

I remember we tried to do something like that with prop196 but I don't remember
if we subsequently decided that it was ridiculous and/or stupid.


More information about the tor-dev mailing list