On Tue, 20 Jun 2017 21:27:35 -0700 David Fifield <david@xxxxxxxxxxxxxxx> 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
Attachment:
pgpG4XqyCEekD.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev