Opened 5 years ago

Closed 5 years ago

#7283 closed task (fixed)

flashproxy-client Windows .exe packages

Reported by: dcf Owned by: aallai
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: aallai Actual Points:
Parent ID: #7166 Points:
Reviewer: Sponsor:

Description

Let's find a good way to package flashproxy-client and the flashproxy-reg-* programs as executables for Windows.

Child Tickets

Change History (7)

comment:1 Changed 5 years ago by aallai

Steps taken to run the Flashproxy client on Windows:

Here is what I had to do to get the client running. This was done using Windows
7 Home Premium 64-bit on a VirtualBox VM. For anything requiring a command
line I used Windows PowerShell, which is decent, you get cp, mv, ls, rm, the basics.
The Windows Git installation also comes with a shell, Git Bash, which I haven't used
but it could be another option.

  1. Install Python. It is a straightforward Windows Installer, it doesn't

add itself to your PATH though, which is needed to run it from a
shell. I set the path by going into Control Panel > System and Security >
System > Advanced System Settings > Environment Variables.

  1. Install OpenSSL. I downloaded a Windows binary from here:

http://slproweb.com/products/Win32OpenSSL.html, a page
recommended by the OpenSSL website. I also had to download
Visual C++ Redistributables from the same page, which I assume
is some sort of libc. They both came as Windows installers. I grabbed
version 1.0.1c.

For actual deployment, we might want to compile it ourselves, so
we can set compile-time options. As a motivating example, the binary
that I have still looks for certificates in /usr/local/ssl, which is unlikely
to exist on Windows.

  1. Install M2Crypto. There are several installers at

http://chandlerproject.org/Projects/MeTooCrypto. SWIG doesn't seem
to be required for these installers to work.

  1. Download pyinstaller at http://www.pyinstaller.org. The zip is better

since Windows can't untar stuff. You can just extract this anywhere, no
installation needed since it is just a python script.

  1. Get an appropriate TBB set up, one that supports pluggable transports.

The simplest way to do this is to get the Obfsproxy bundle at
https://www.torproject.org/projects/obfsproxy.

  1. Get the flashproxy code.
  1. Now you should be able to bundle the executables. To do this

just run
pyinstaller.py --onedir <python script to bundle>
This will create a .spec file containing build instructions for
pyinstaller, which you can customize. It also creates a build directory
with log files and a dist directory with the executable and DLLs.

The onedir option conveniently puts everything in one directory. I
also tried the onefile option, but that doesn't work so well for us, since
the one file is actually a self-extracting archive, which creates a temporary
directory to run the executable in, which doesn't contain the registration
methods.

The multipackage function described in the manual is a bit iffy, it
packages all the right dependencies but only creates one executable.
It looks pretty easy to get working by fiddling around with the spec files though.
To simulate it I simply packaged the three executables separately using
--onedir, then I copied everything into a single directory. That way there is
no duplication of common DLLs like the python runtime.

  1. Some things need to be renamed.

M2Crypto.__m2crypto.pyd -> __m2crypto.pyd. The naming conventions M2Crypto
uses give pyinstaller-bundled EXEs some trouble.

flashproxy-reg-*.exe -> flashproxy-reg-*, to match what flashproxy-client tries to run.

You might want to keep flashproxy-client.exe ending in .exe, otherwise if you
try and run it from a shell Windows won't know what to do with it. Alternatively
you can rename it and run it from the Python interpreter using subprocess.

  1. Configure port forwarding. This will vary depending on your hardware.
  1. Now you should be able to run flashproxy-client. In the Vidalia advanced

settings change the torrc to the one included with the flashproxy code and
restart Tor.

comment:2 Changed 5 years ago by dcf

Status: newneeds_revision

aallai made a branch implementing this at https://github.com/aallai/flashproxy/tree/make_exe.

I made a branch too at https://git.torproject.org/user/dcf/flashproxy.git branch make_exe; please pull from it.

Here are notes on the changes:

  • Please see if there is a way to build all the executables with one invocation of PyInstaller. To do this, you might have to create your own spec file with multiple calls to Analysis. Here are some example links:
  • I want to keep the .exe extensions on files. Running the registration helpers with --register worked just fine for me with the .exe extensions, with no code changes.
  • See if there is a way to cause PyInstaller to put its scratch files in a subdirectory. As it is, it implicitly uses the name dist in the current directory, which conflicts with our use of the same name.
  • After PyInstaller, there shouldn't be any leftover build files or autogenerated spec cruft. git status should be clean. A nice way to do this might be to make the intermediate files .INTERMEDIATE in the makefile; another way is to explicitly delete them.
  • Is it possible to make the build fail if m2crypto is missing? I tried building an exe before installing it, and the build worked, though of course flashproxy-reg-email didn't work.

What I would ideally want is a dist-exe target that builds flashproxy-client-VERSION-win32.zip, which contains the same files as flashproxy-client-VERSION.zip, except that the Python script files are replaced by .exes. All the auxiliary PyInstaller files are ideally in a subdirectory within the zip.

comment:3 Changed 5 years ago by aallai

Status: needs_revisionneeds_review

I have implemented most of the changes in the comment above at https://github.com/aallai/flashproxy.git,branch make_exe. 

The zip file produced right now has all the DLLs in the same directory as the exes. I am looking into

how we could put them in a subdirectory, right now it looks like this involves writing an XML file called a manifest, which tells windows where to find your program's DLLs. 

comment:4 in reply to:  3 Changed 5 years ago by dcf

Replying to aallai:

how we could put them in a subdirectory, right now it looks like this involves writing an XML file called a manifest, which tells windows where to find your program's DLLs. 

If this is cumbersome, don't worry about it. Writing an XML manifest file sounds cumbersome. I didn't think previously about the directory containing the executable being in the default search path for DLLs. I guess Windows users are used to getting a pile of DLLs in their downloaded archives.

comment:5 Changed 5 years ago by aallai

It does look kind of cumbersome. The Tor Browser Bundle has the OpenSSL DLLs just lying around too, so yeah it shouldn't surprise users too much. 

comment:6 Changed 5 years ago by dcf

Merged the make_exe branch. make dist-ext creates a zip file with executable versions of the client programs. There are three programs that share a common Python runtime. The file is 6.3 MB (versus 43 KB for the equivalent package without a Python runtime).

comment:7 Changed 5 years ago by dcf

Resolution: fixed
Status: needs_reviewclosed
Note: See TracTickets for help on using tickets.