Develop an experimental Python pluggable transport library
In sponsor F year 2 deliverable 19 (legacy/trac#5549 (moved)) we concluded that writing a Python pluggable transport library is feasible. This ticket is about the actual development of an experimental Python library for pluggable transports. Deliverable 19 says "If we decide it's smart, get it started," but it doesn't make any promises how far we'll get. That's why this is a sponsor Z deliverable that isn't tied to the sponsor F milestone in November.
George outlined a few possible next steps (which should probably become child tickets soon):
-
George knows a couple of people who are coding Python pluggable transports; one of them is wiretapped with banana phone, another one is the Portland university guys. He wants to prepare a pluggable transport library for them. Roger adds that flash proxy also has a Python part. In general, Roger thinks that looking at other Python pluggable transports and trying to help them all use our framework should be part of this deliverable.
-
George thinks that most of the future transports we are thinking of can be handled (performance-wise) by a Python program. He wants to prepare an obfs2-like thing and benchmark it by feeding it with thousands of connections. George wants to see how many of them it will handle (he expects many).
-
George also wants to prepare a very lite managed proxy library, which will read environment variables etc. He also wants to write a very simple pluggable transport in Python which will use that managed proxy library.
-
George wants to evaluate py2exe (and the other similar things).
Here are a few more random notes which seem relevant:
-
Nick suggests that we could do something minimalistic with twisted. George hopes to be able to use all the other web protocols baked in twisted for transports.
-
George will try to learn the truth about bytearrays and cryptographic material overwriting. The idea is that by using bytearrays in Python one can actually overwrite cryptographic material "securely".