Opened 3 weeks ago

Last modified 2 days ago

#32550 assigned enhancement

Static tor in docker container

Reported by: thymbahutymba Owned by: phw
Priority: Medium Milestone:
Component: Circumvention/Obfs4 Version:
Severity: Normal Keywords: docker, s30-o24a2
Cc: cohosh, phw Actual Points:
Parent ID: #31281 Points: 2
Reviewer: Sponsor: Sponsor30-can

Description

I was wondering about how to improve the docker image. The current version of provided image, in such case for bridges, uses debian. This ends up in a "big" image that, in my honest opinion waste a lot of space.
In order to improve the deployment and the space required by such container, which can be even extended for all relay, I wrote a Makefile for statically build tor. Once there is a statically build of tor, it should be enough provide just it inside the container.

PREFIX=$(shell pwd)/dist
RELEASE=$(shell pwd)/release

TOR=https://dist.torproject.org
TOR_VER=0.4.1.6

LIBEVENT=https://github.com/libevent/libevent/releases/download
LIBEVENT_VER=2.1.11-stable

OPENSSL=https://github.com/openssl/openssl/archive
OPENSSL_VER=1_0_2t

ZLIB=https://zlib.net
ZLIB_VER=1.2.11

CLEAN_DIRS=$(dir .)

all: tor

tor: tor-${TOR_VER} libevent libseccomp zlib openssl
    cd $< && \
        ./configure \
            --prefix=${RELEASE}             \
            --enable-static-tor             \
            --with-openssl-dir=${PREFIX}    \
            --with-libevent-dir=${PREFIX}   \
            --with-zlib-dir=${PREFIX}       \
            --disable-asciidoc              \
            --disable-system-torrc          \
            --disable-seccomp               \
        && $(MAKE) $(MAKEFLAGS) && $(MAKE) install

libevent: libevent-${LIBEVENT_VER}
    cd  $< && \
        ./configure --prefix=${PREFIX} --enable-shared=no && \
        $(MAKE) $(MAKEFLAGS) && $(MAKE) install

openssl: OpenSSL_${OPENSSL_VER}
    cd $< && \
        ./config no-shared no-dso no-zlib --prefix=${PREFIX} && \
        $(MAKE) depend && $(MAKE) $(MAKEFLAGS) && $(MAKE) install_sw

zlib: zlib-${ZLIB_VER}
    cd $< && \
        ./configure --prefix=${PREFIX} --static && \
        $(MAKE) $(MAKEFLAGS) && $(MAKE) install

## Download and extract source if required

tor-${TOR_VER}:
    wget -qO- ${TOR}$@.tar.gz | \
        bsdtar xzf -

libevent-${LIBEVENT_VER}:
    wget -qO- ${LIBEVENT}/release-${LIBEVENT_VER}/$@.tar.gz | \
        bsdtar xzf -

OpenSSL_${OPENSSL_VER}:
    wget -qO- ${OPENSSL}/$@.tar.gz | \
        bsdtar xzf -
    mv openssl-$@ $@

zlib-${ZLIB_VER}:
    wget -qO- ${ZLIB}/$@.tar.gz | \
        bsdtar xzf -

Child Tickets

Change History (5)

comment:1 Changed 3 weeks ago by phw

Component: CircumventionCircumvention/Obfs4
Keywords: docker added
Owner: set to phw
Status: newassigned

So the idea is to use a more lightweight image, like alpine, and copy a statically-compiled tor binary into the image? I like the idea of making our image more lightweight but I worry about the additional complexity in the build process. For example, we also need to include Tor's GeoIP database because otherwise the bridge won't be reporting the country codes of its clients. Debian's tor package depends on tor-geoipdb, which takes care of this for us.

comment:2 in reply to:  1 Changed 3 weeks ago by thymbahutymba

Replying to phw:

So the idea is to use a more lightweight image, like alpine, and copy a statically-compiled tor binary into the image?

Yes that is the idea.

I like the idea of making our image more lightweight but I worry about the additional complexity in the build process. For example, we also need to include Tor's GeoIP database because otherwise the bridge won't be reporting the country codes of its clients. Debian's tor package depends on tor-geoipdb, which takes care of this for us.

Actually this problem does not exist because looking at the debian geoipdb package tor-geoipdb the interesting file are /usr/share/tor/geoip*; if we look at the result from the tor statically compilation these file are already present.

$ ls -al etc/tor/ share/tor/ bin/
bin/:
total 23816
drwxr-xr-x 2 alarm alarm     4096 Nov 19 22:03 ./
drwxr-xr-x 5 alarm alarm     4096 Nov 20 16:57 ../
-rwxr-xr-x 1 alarm alarm 15843708 Nov 19 22:03 tor*
-rwxr-xr-x 1 alarm alarm  3934620 Nov 19 22:03 tor-gencert*
-rwxr-xr-x 1 alarm alarm     1375 Nov 19 22:03 torify*
-rwxr-xr-x 1 alarm alarm  3253832 Nov 19 22:03 tor-print-ed-signing-cert*
-rwxr-xr-x 1 alarm alarm  1335172 Nov 19 22:03 tor-resolve*

etc/tor/:
total 20
drwxr-xr-x 2 alarm alarm  4096 Nov 19 22:03 ./
drwxr-xr-x 3 alarm alarm  4096 Nov 19 22:03 ../
-rw-r--r-- 1 alarm alarm 11663 Nov 19 22:03 torrc.sample

share/tor/:
total 7356
drwxr-xr-x 2 alarm alarm    4096 Nov 19 22:03 ./
drwxr-xr-x 3 alarm alarm    4096 Nov 19 22:03 ../
-rw-r--r-- 1 alarm alarm 4647198 Nov 19 22:03 geoip
-rw-r--r-- 1 alarm alarm 2871417 Nov 19 22:03 geoip6

comment:3 in reply to:  description ; Changed 3 weeks ago by thymbahutymba

I was building again all and I saw that I've made two mistake in the Makefile. In order to fix it so that you are able to build by yourself without any trouble here the fixing.

  • In tor target remove libseccomp (that is not present at all);
  • In tor-${TOR_VER} i forgot one slash into the url. The correct url is: ${TOR}/$@.tar.gz.

Forgive me about those mistake, I'm really sorry.

comment:4 Changed 2 days ago by phw

Keywords: s30-o24a2 added
Parent ID: #31281
Points: 2
Sponsor: Sponsor30-can

Replying to thymbahutymba:

Replying to phw:

I like the idea of making our image more lightweight but I worry about the additional complexity in the build process. For example, we also need to include Tor's GeoIP database because otherwise the bridge won't be reporting the country codes of its clients. Debian's tor package depends on tor-geoipdb, which takes care of this for us.

Actually this problem does not exist because looking at the debian geoipdb package tor-geoipdb the interesting file are /usr/share/tor/geoip*; if we look at the result from the tor statically compilation these file are already present.


Gotcha, that certainly makes things easier.

Another reservation I have is that this approach requires us to keep track of the latest versions of dependencies and their security vulnerabilities, which takes time and effort. Every time we're creating a new docker image, we need to figure out what the latest version of OpenSSL etc. is. A Debian package however takes care of this for us.

comment:5 in reply to:  3 Changed 2 days ago by phw

Replying to thymbahutymba:

I was building again all and I saw that I've made two mistake in the Makefile. In order to fix it so that you are able to build by yourself without any trouble here the fixing.

  • In tor target remove libseccomp (that is not present at all);
  • In tor-${TOR_VER} i forgot one slash into the url. The correct url is: ${TOR}/$@.tar.gz.

Forgive me about those mistake, I'm really sorry.


No worries! With these changes, I managed to build a statically-compiled tor binary with your Makefile.

Note: See TracTickets for help on using tickets.