Create a configure flag for building a static Tor

added component::core tor/tor priority::low resolution::fixed status::closed tor-client type::enhancement labels

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.

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...

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

Trac:
Component: - Select a component to Tor Client

I've updated my branch - it won't work on Mac OS X: http://developer.apple.com/library/mac/#qa/qa2001/qa1118.html http://pastebin.com/6qtPp2ij

Branch for review: https://gitweb.torproject.org/ioerror/tor.git/shortlog/refs/heads/static-work

Okay, and this is for applying to master?

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

Trac:
Status: new to needs_review

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.

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?

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.

Trac:
Description: I've created a static configuration flag for Tor and put it into a git branch called 'static-tor' with my work.

to

N/A

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?

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.

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.

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

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().

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.

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

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.

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?

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.

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.

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

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Keywords: N/A deleted, tor-client added

Trac:
Component: Tor Client to Tor

closed

moved to tpo/core/tor#2702 (closed)

Create a configure flag for building a static Tor

Child items 0

Activity