On Wed, Jun 21, 2017 at 01:16:20PM +1000, teor wrote:
In general, is there a separate document or proposal that describes how Tor will implement the relevant interfaces? There doesn't seem to be much on Tor-specific issues in this spec.
There is one "Tor" note in the spec, maybe it should be in that separate document? Or maybe there should be more Tor notes in the spec?
As I understand it, one of the goals of the PT 2.0 spec is to make it easier for projects *other* than Tor to use pluggable transports. The current spec (the 1.0 spec) basically doesn't work for anyone other than desktop Tor--this is something we've heard over and over from other projects that use circumvention, and Brandon is well plugged in to those conversations. Even closely affiliated projects like Orbot haven't been able to use pluggable transports strictly according to the spec, because of the various constraints on mobile platforms.
What various circumvention developers have said they prefer, is a Go-based API. They would rather link against a library, than do the whole subprocess-and-stdout thing that the PT 1.0 spec requires. That's the reason for introducing the new Go stuff in the 2.0 spec. Inside and outside Tor, a lot of projects have converged on implementing their circumvention code in Go. The API of the 2.0 spec is based on the internal architecture of obfs4proxy, which is de facto the main implementation of most of Tor's pluggable transports.
If I understand correctly, Tor wouldn't have to implement glue code to interface with the Go API. It could continue spawning subprocesses, similar to what it does now. The executables it invokes, if they are written in Go, will likely internally use a PT library that uses the 2.0 spec's API, but Tor wouldn't have to know those details.
PT 1.0 succeeded in being "pluggable" in one sense: it's easy to hotswap a lot of circumvention technologies within Tor. But it failed in being "pluggable" in another sense: it's not easy to share common transport modules beyond Tor (in either direction). It would be great if the new spec can realize that second sense of pluggability.