-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/07/2015 12:29 AM, David Fifield wrote:

Way way back when pluggable transports were first integrated into Tor Browser, we tried compiling Python and it was too problematic to be worth it. Here is the comment you want to read:

https://trac.torproject.org/projects/tor/ticket/9444#comment:18 https://trac.torproject.org/projects/tor/ticket/9444#comment:20

Those comments are two years old now. Maybe things have changed and it's easier to cross-compile for Windows now. If it's something you have expertise with, it'd be great if you tried it!

Hi David, thanks for the reply. I don't have any particular expertise with this myself (I've done some reproducible build work using Gitian but it was all fairly standard C++ code), but I'm aware that the Bitcoin wallet Armory is attempting to do Gitian builds for Windows, and a lot of their code is Python. I've pointed their reproducible build specialist to this thread. Armory's progress on this isn't very complete yet (they're still working through bugs introduced by cross-compiling Python), but maybe they'll learn something from your notes, and maybe they'll be able to move things forward. Cheers, - -Jeremy Rand -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV7OrfAAoJEAHN/EbZ1y06MgsP/ji+pb+yq5s4JgSxErv4ChRh VXhhtmtTG4bP4IaGq0FPRcBDh6wPMQJaXxWJnRbSW/bSbb822i+IeAW9xS6+4iY9 CxocZk3L6tN4QH5yjFlLN63BzLfVCQKrlpZVHthj/98teBborVhFc4eHBS6QWN6L dThAHIBeHt+aHi48V/QvVPzjVRptAlXqOx4KYaC+2O+sDo7ctwWNKn4iXPZ0xRDT v+Hzj2ZXuCOsmTJrjHuz+ZfprZPRJHbIepDfvTjECjyKbN95W+JKNsj+0f+qdxau fiJVpgKq3x7OAgD7JFx8AE7m+MaTJsr6ufb5/u5t/DfQ/x0/QopsHNGlX240BsuZ TgeB8HgeY/5ahkoLlXkQwLTzTV9vgum65ki5IeWpv5/c1CxhaWFsAe2rMBTxnutQ 2m8+wHtybzc84jt8Ut6SmHOFvWNsnjcDgMrFMEodI6xe18FL3qNQQpq1A/NEcTIV VGS+xLtm8rI8wgEDe/nRAz6Zj6jk3fXTXRBb94pmNAwiw6ayohtC6nzTmjsjBuDu LYoG/ft0B/B0wOB2sxVuhtifJUiA6MGW6aHt0361oGr3qPCDEgPAX9b1YnkB6LRq skQWJ76aDhzr56s7Awn2pO4JAORp0vnCUac93yL2Ek253TgkBKX7EczN6u/0E0AY wjIzPkJ2ABkDjPMWUnlY =rCHg -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/09/2015 06:43 PM, Brandon Wiley wrote:

Another option here, besides getting python to build in gitian is to phase out support for python-based pluggable transports. It's something to consider at least. Which transports are still only available in python?

Indeed -- the reason I originally asked this question was to evaluate whether Namecoin (of which I'm a developer) should keep developing code in Python or whether we should port that code to Golang. We really want reproducible builds, and based on the info David and Joseph have shared, Namecoin is probably going to (where feasible) port to Golang (which Tor is successfully building reproducibly with very minimal code). I'm curious whether the Tor devs have come to a similar conclusion. Cheers, - -Jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8H+MAAoJEAHN/EbZ1y06utEQAIrpmeB7k6UDqDpmeeEdOrBB cqKsxg28UmNo4c32+sY+ocouYBPAgqKAQwXyMkUI4sMvpPXsbWSjf8UdyXxPdcT0 JfUr/skxEf/9jfHNccHm0UfOymYeNoTsAvPTUfOxbZ2F1ZfQ49gfKzqfcntXqpKa B3nVoQSAz8xTWeIvzJdrdZgMlNDc61Xvv4UznALJItrpGEC33RK8p4la9SwC2iss /v/YtuqI7fPzCwzrDnQOU7ol3j40lRKhHbskTwKFBNmDp9hEKUbgQJbloiNYfXwg cS7Q3fYM+JpPyIgJwMTV1CwTSrcF+rGLhG2gRLeCSMzKF9c8MAVCOCdpNjeKxcFx Rc6RjWw4ClyXLyB24BrKLipd9gY0I6DWI29cEfTVKfcyHN+0qFvcecBjrFsCGWYE RkRDVuDSRzRnIdz/kIhcxpGhezvwl09PRGCuJ8f/oLGk79QGpkqXunv2gvV9AlNM MmIffRoEhvhqvPGf6sVx0xxphP9sk6WiCKb6n8onrQRcPVN4mPG6MjQ+eyxPOsCa Eo+BLb78c4CVzNnhher1HeuBbR4UxZvi66V8NhcPW4pSUZamIrIxVsnwAsV70vBP 2NDfkGgpcaHVr+nr5XvccGJZWsFcYv38GlB9PuwxSNCmJI6pALQic7ArS6VMS7QZ H8jm1cUe+2jSeFMNLiq/ =uyhm -----END PGP SIGNATURE-----

On Wed, Sep 09, 2015 at 03:33:24PM -0400, Brandon Wiley wrote:

I am in favor of standardizing on the Go codebase for pluggable transports that ship with Tor. This is something we talked about at the last developer meeting. The reason I favor this is not for reproducible build reasons, but because maintaining four implementations (C, Python, C++, and Go) is confusing for PT developers. As far as I know, since the last developer meeting all Tor products have been migrating towards shipping the Go PT implementation so that they can get obfs4 support. Last I checked, some of Tor products are also shipping other PT implementations in order to maintain access to transports not available in Go. I imagine that there is some time in the future where there will no longer be any bridges available for the older transports and so bundling clients for them will no longer be necessary. However, I don't know what the current level of use for non-Go transports is. I'd love to know if someone has those stats.

You can see the usage of each transport here: https://metrics.torproject.org/userstats-bridge-transport.html?graph=usersta... obfs2 - Go obfs3 - Go obfs4 - Go meek - Go ScrambleSuit - Go flash proxy - Python FTE - Python

On Wed, 9 Sep 2015 17:20:11 -0400 Brandon Wiley <brandon@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.

On Thu, 10 Sep 2015 10:20:59 -0400 Brandon Wiley <brandon@blanu.net> wrote:

I'm not advocating that the various PT implementations be abandoned, just that we have a common implementation across products when possible. If I recall correctly, there was a time when TBB, Tails, and Orbot were all shipping different implementations. I think the current state of PT implementation deployment is the following:

TBB: Go, Python Tails: Go Orbot: Go, C++ (on x86)

That's correct. It's worth noting that the Python component of TBB is almost entirely FTE that hovers around ~200 users. Out of those, I am unsure how many use FTE because it is the only thing that works in their environment.

The benefit of having the Go implementation ship with all products is that PT authors can target one implementation and achieve deployment across all of the products.

Sure. Go would be a fine choice for people, but I'd like it to be explicit that I'm open to more options, even if it means reducing the deployment base if that's what it takes for people to write something (I'd rather see more circumvention methods, than fewer).

As far as reproducibility of builds goes, if a reproducible Python build is a challenge, an alternative is to port FTE to Go and retire flashproxy.

Or port both to Go (flashproxy would be easy)/deprecate both. Regards, -- Yawning Angel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/09/2015 07:33 PM, Brandon Wiley wrote:

I also don't know how well reproducible builds work with Go, so if someone knows that would be interesting information.

Take a look here: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitia n/descriptors/windows/gitian-pluggable-transports.yml A number of Go projects are built in that Gitian script. It looks pretty straightforward. (I haven't tested that Gitian script for determinism, but I assume that Tor wouldn't be using it if it weren't deterministic.) - -Jeremy Rand -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8NPPAAoJEAHN/EbZ1y06dcsQAICuZGa6o8xWpjXLoYLbCiVO sPcw+GM0a5q+3JyHKOKGBhx2MVTKcB6MHrBvDzIjoUUL2J6j/5+/3mK+zwiKEaK5 JIlchn0IlzOp9XiSlLl+we2tSju9htMLYyvbpVnTMi3ebx4TyLN5VXKd9kC1ZZA0 hi8ncc1bFpld7Bo5VNPIEvM25hSKmqv9yXMrR40IYE2RiYmxQ2FbpPUMia1aqF9L 5tb0k7GnSMJ/2Pago/gQbWYKCBfdi2RK2MmqydBlqtgI43wlnizipZbNSmktpXq1 UbhbRrs8r/MOAZk9dFd+VyomKy1msBJ6c5gnY+CpWh+KSrnqnHJinZM617pH02CT idTLxua7Z3qDuv131cUOvowKSuB2fYMMGSFxVx07UVLJMjlx/YCnjAGinQuuBwWE K8OQ4DC+bOkZb6JcSYuntLapUQi5ukcsdFiSV6+iP82a3wCQfNbIpjq2HXQhf6em GBR4YqtEvWCo4Ia3OYIS5RlTRSU/+Rq1cudIrtccQ26wfmz+X1jq6oUC16czp/Bb P2rlTigxPui+lpBHYpTkvpX18UvSF3xEFSsBc9QTxsQc+gCWsR+Z11NHYzzbHhGA qrYCnBVfhp0MePMhjoxAWRTpOQNft72RHw27WiTAd4SrekRDTiqPuuPp++7hKOoc AwkePEMJKgkt8lrJaoVz =BiZi -----END PGP SIGNATURE-----