[tor-dev] Reproducibility of Pluggable Transports python.msi

[Yawning Angel]

On Wed, 9 Sep 2015 17:20:11 -0400
Brandon Wiley <brandon at blanu.net> wrote:
> Thanks David, great info! Last time I checked, I think the C
> implementation was also still shipping with something, I think Orbot
> for Android. Perhaps this is also for either flash proxy or FTE
> support, since Python is not the best option on Android.

Orbot used to use obfsproxy (C), migrated to obfsclient (C++) and the
main build uses obfs4proxy (Go) these days.  I heard that Android x86
might still need to use the C++ code, but I'm not sure.

> From the graphs it looks like FTE is still in use, but that flash
> proxy seems to no longer be used.

It wasn't really every used due to NAT related issues. WebRTC may be
the way forward here but it will be an entirely different codebase.

> If I recall correctly, the core FTE code is actually written in C and
> is just using the Python PT implementation with Python-C bindings to
> the FTE library. So a port of the FTE PT to the Go PT implementation
> seems possible.

The core FTE code was originally in C++, but IIRC it's in python now.

FWIW, I don't particularly think that there must be One True PT
language[0], I just recommend Go over the other alternatives due to it
being both memory safe and easy to build on mobile. If someone writes a
new PT in Python, I don't consider it a deal breaker, though it won't
be as useful due to the difficulty of mobile support.

All of this sort of ties into the other thread where people are talking
about buffing up pyptlib (might make sense), and further deprecating
obfsproxy (Python).  I don't particularly see a reason to do either
things, though the Debian people apparently see obfsproxy as the
program and not a library, when it's both.

Regards,

-- 
Yawning Angel

[0]: MUST be able to be built deterministically. SHOULD be memory
safe.  Past that, people can do what they want.  If they ignore the
SHOULD clause, the code needs to undergo more thorough auditing before
it will be deployed into production.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150910/c7436939/attachment-0001.sig>