[tor-dev] Pluggable Transports 2.0 Specification, Draft 2

[Yawning Angel]

On Tue, 20 Jun 2017 21:27:35 -0700
David Fifield <david at bamsoftware.com> wrote:
> 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.

This is basically totally and utterly wrong.

https://gitweb.torproject.org/orbot.git/tree/orbotservice/src/main/java/org/torproject/android/service/TorService.java#n1691

(The extra acrobatics are for programatically generating the config to
 handle the binary's install path being system dependent, which is
 beyond the scope of the PT spec itself.)

Orbot can use normal Pluggable Transports just fine, and has at various
points in time used:

 * obfsproxy (C)
 * obfsclient (C++)
 * obfs4proxy

All basically exactly as specified by the Pluggable Transports spec.
The only problem in this regard has been "Python on Android was a
nightmare" which precluded the deployment of obfsproxy (Python).  This
has little to nothing to do with the Pluggable Transport spec itself.

Perhaps you mean iOS?  In which case, yeah, implementing something
that's based around fork + exec, on an OS that doesn't allow that, is
difficult, go figure (https://github.com/mtigas/iObfs for how it's
done).

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

I don't think that's a good idea, because the API was written by me, for
me, to fit my use-cases (and I'm more and more dissatisfied with Go, to
the point where all my new "for fun" code is going to be in C++ or D).

But if it works for them, great I guess.  I didn't use the API when I
was working on basket2, so this has 0 impact on anything I will be
doing, or anything that I've written.

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

I still don't understand what was so hard about implementing the old
API, on anything but iOS.

The "2.0" spec still doesn't have any provisions for using AF_LOCAL
instead of the loopback interface, go figure.  It's not as if I bring
it up every time this topic comes up or anything right?

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170621/8c46b49d/attachment.sig>