Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#2702 closed enhancement (fixed)

Create a configure flag for building a static Tor

Reported by: ioerror Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: nickm helix Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Child Tickets

Change History (25)

comment:1 Changed 9 years ago by ioerror

I've produced a working static Tor binary but creating this causes a few warnings:

Making all in or
make[3]: Entering directory `/tmp/tor/src/or'
gcc  -g -O2 -static -Wall -g -O2 -fno-strict-aliasing -L/tmp/static-tor/zlib-1.2.5 -L/tmp/static-tor/openssl-0.9.8r/ -L/tmp/static-tor/libevent-1.4.14b-stable  -o tor tor_main.o ./libtor.a ../common/libor.a ../common/libor-crypto.a ../common/libor-event.a /tmp/static-tor/zlib-1.2.5/libz.a -lm /tmp/static-tor/libevent-1.4.14b-stable/libevent.a -lrt /tmp/static-tor/openssl-0.9.8r//libssl.a /tmp/static-tor/openssl-0.9.8r//libcrypto.a  -lpthread -ldl 
/tmp/static-tor/openssl-0.9.8r//libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
dso_dlfcn.c:(.text+0x5b4): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
../common/libor.a(compat.o): In function `get_user_homedir':
/tmp/tor/src/common/compat.c:1502: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libtor.a(control.o): In function `getinfo_helper_misc':
/tmp/tor/src/or/control.c:1379: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
../common/libor.a(address.o): In function `tor_addr_lookup':
/tmp/tor/src/common/address.c:171: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
make[3]: Leaving directory `/tmp/tor/src/or'

This produces a "working" Tor binary:

% file src/or/tor
src/or/tor: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.15, not stripped
%  ldd src/or/tor
	not a dynamic executable

Anything interacting with PAM or dlopen will cause serious failures.

comment:2 Changed 9 years ago by ioerror

This produces a Tor binary that is 6.5M (6802809 bytes) on my X86_64 system and when stripped the binary is only 3.4M (3489520 bytes) in size.

This should be suitable for sending to users via email and/or basic Tor bootstrapping needs once the warnings above have been solved.

I suppose we also are now on par with many other "no install required" proxies for whatever that's worth...

comment:3 Changed 9 years ago by ioerror

Here's a snapshot of my patch to create this static build of Tor:
https://gitweb.torproject.org/ioerror/tor.git/commitdiff/efce4682e081c7f9d3fd9e53553296ceb60968e8

That's a WIP, so if that link is broken, hit this branch:
https://gitweb.torproject.org/ioerror/tor.git/shortlog/refs/heads/static-tor

comment:4 Changed 9 years ago by rransom

Component: - Select a componentTor Client

comment:7 Changed 9 years ago by nickm

Okay, and this is for applying to master?

For the changelog messages, what versions are these bugfixes on?

comment:8 Changed 9 years ago by nickm

Status: newneeds_review

comment:9 Changed 9 years ago by Sebastian

We shouldn't merge this as-is I believe: static builds on OS X don't work generally, and some of the help text is duplicated/slightly wrong. I'll work on a followup patch for the things I noticed.

comment:10 Changed 9 years ago by Sebastian

Then, before I forget: What is the usecase here? I can see how statically linking libevent, zlib and openssl can help, but how does an explicit -static make us better?

comment:11 in reply to:  7 Changed 9 years ago by ioerror

Description: modified (diff)

Replying to nickm:

Okay, and this is for applying to master?

For the changelog messages, what versions are these bugfixes on?

Yeah, all of this applies on master cleanly - that's what I've been testing against.

comment:12 in reply to:  9 Changed 9 years ago by ioerror

Replying to Sebastian:

We shouldn't merge this as-is I believe: static builds on OS X don't work generally, and some of the help text is duplicated/slightly wrong. I'll work on a followup patch for the things I noticed.

I think it's fine that it doesn't work for Mac OS X - we should just explain that as a limitation _or_ encourage them to build the required Mac OS X module.

We could hack up the autoconf to complain about using this flag when building on Mac OS X. Is what you think think would make for a reasonable compromise?

comment:13 in reply to:  10 Changed 9 years ago by ioerror

Replying to Sebastian:

Then, before I forget: What is the usecase here? I can see how statically linking libevent, zlib and openssl can help, but how does an explicit -static make us better?

There are many uses of a fully static Tor:

We'll have a very small, stripped down binary to be used for bootstrapping
This will give us a very small option for GetTor to be used with mail providers that have strict limits
Debugging OpenSSL/zlib/libevent hacks on the client side during censorship events
Allowing people to easily have a single Tor binary for academic projects
Easy tests of Tor on strange platforms with a cross compiler (build & scp over)
Tor Browser deployments where the system libraries are wonky or perhaps even bad
A user requested it and I was surprised it wasn't so easy to build statically

I can think of a few other things too.

comment:14 Changed 9 years ago by Sebastian

I'm still not fully convinced, it seems that a most of your points are perfectly achievable without an entirely static tor. I think we should definitely merge the first patch in your branch (to answer nickm's question, it is a bugfix on 0.2.1.23/0.2.2.8-alpha, where statically linking libevent was introduced), but consider whether we really want entirely static builds of Tor.

comment:15 Changed 9 years ago by Sebastian

I've pushed a bug2698 branch for the bugfix. We should use this bug for the feature.

comment:16 in reply to:  14 Changed 9 years ago by ioerror

Replying to Sebastian:

I'm still not fully convinced, it seems that a most of your points are perfectly achievable without an entirely static tor.

How would you begin to expect to say, survive a backdoored libc (think RedFlag Linux) without a totally static Tor?

A user requested this feature in the first place for a project on Linux where they expect a static build to work but they don't want to open any libraries or do anything on the system other than exec().

comment:17 Changed 9 years ago by nickm

I'm not totally convinced that the redflag use case is a great idea, but I'm not opposed to merging this code: people come up with weird applications for build flags all the time!

Having this work on all platforms also isn't necessarily a requirement.

comment:18 Changed 9 years ago by Sebastian

Ok. I should push my cleanup patch then, before we merge.

comment:19 Changed 9 years ago by Sebastian

Eh, forgot to update this. Cleanup patch is in static-work in my repo. I still wonder if this static Tor works on a different computer than the one it was built on, the warnings during make seem to indicate to me that it might well fail. I haven't tested that yet, but will do that test.

comment:20 Changed 9 years ago by Sebastian

Indeed, the binary doesn't run on other computers. It fails with a "Socket creation failed." warning. I'm not sure what to do here. ioerror, nickm?

comment:21 Changed 9 years ago by ioerror

You'll have to build Tor on a system that is very similar to the system where you want it to run. I don't think you'll find it easy to run 64bit binaries on 32bit machines, etc.

comment:22 Changed 9 years ago by ioerror

Your cleanup patch seems fine - if that's the one we want to merge and you've tested it, I think it's probably the best revision so far.

comment:23 Changed 9 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Ok, merged sebastian/static-work, with a changes file. Thanks, all!

comment:24 Changed 7 years ago by nickm

Keywords: tor-client added

comment:25 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.