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

[Brandon Wiley]

It is my understanding that a sponsored project is coming up to work a
pluggable transport 2.0 specification and implementation. I've also heard
that the first step for this is to have a meeting where we get together
with people that either use pluggable transports or implement them, for the
purpose of soliciting feedback on the existing specification and gathering
design requirements for 2.0. So perhaps the drafting of a new specification
should be deferred until this is organized. Although of course any feedback
gathered in this email thread can also be presented at the meeting.

On Mon, Sep 7, 2015 at 6:45 PM, Yawning Angel <yawning at schwanenlied.me>
wrote:

> 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).
>   * 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.
>
> Regards,
>
> --
> Yawning Angel
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150914/18916d54/attachment-0001.html>