Tor-ramdisk 20151215 released: libressl to the rescue!

If you’ve read some of my previous posts, you know that I’ve been maintaining this hardened-Gentoo derived, uClibc-based, micro Linux distribution called “tor-ramdisk”.   Its a small image, less than 7 MB in size, whose only purpose is to host a Tor relay or exit node in a ramdisk environment which vanishes when the system is shut down, leaving no traces behind.  My student Melissa Carlson and I started the project in 2008 and I’ve been pushing out an update with every major release of Tor.  Over the years, I automated the build system and put the scripts on a git repository at gitweb.torproject.org that Roger Dingledine gave me.  If you want to build your own image, all you need do is run the scripts in the chroot of a hardened amd64 or i686 uClibc stage3 image which you can get off the mirrors.

Recently, upstream switched the tor-0.2.7.x branch to depend on openssl’s elliptic curves code.  Unfortunately, this code is patented and can’t be distribute in tor-ramdisk.  If you read the tor ebuilds, you’ll see that the 0.2.7.x version has to DEPEND on dev-libs/openssl[-bindist] while the 0.2.6 only depends on dev-libs/openssl.  Luckily, there’s libressl which aims to be a free drop in replacement for openssl.  Its in the tree now and almost ready to go — I say almost because we’re still in the transition phase.  Libressl in Gentoo has been primarily hasufel‘s project, but I’ve been helping out here and there.  I got a few upstream commits to make sure it works in both uClibc and musl as well as with our hardened compiler.

So, this is the first tor-ramdisk release with libressl.  Of course I tested both the amd64 and i686 images and they work as expected, but libressl is new-ish so I’m still not sure what to expect.  Hopefully we’ll get better security than we did from openssl, but I’ve got my eyes out for any CVE’s.  At least we’re getting patent free code.

Tor-ramdisk has been one of those mature projects where all I have to do is tweak a few version numbers in the scripts, press go, and out pops a new image.  But I do have some plans for improvements: 1) I need to clean up the text user interface a bit.  Its menu driven and I need to consolidate some of the menu items, like the ‘resource’ menu and the ‘entropy’ menus.  2) I want to enable IPv6 support.  For the longest time Tor was IPv4 only but for a couple of years now, it has supported IPv6.  3) Tor can run in one of several modes.  Its ideal as a relay or exit node, but can be configured as client or hidden service for processes running on a different box.  However, tor-ramdisk can’t be used as a bridge.  I want to see if I can add bridge support.  4) Finally, I’m thinking of switching from uClibc to musl and building static PIE executables.  This would make a tighter image than the current one.

If you’re interested in running tor-ramdisk, here are some links:

i686:
Homepage: http://opensource.dyc.edu/tor-ramdisk
Download: http://opensource.dyc.edu/tor-ramdisk-downloads
ChangeLog: http://opensource.dyc.edu/tor-ramdisk-changelog

x86_64:
Homepage: http://opensource.dyc.edu/tor-x86_64-ramdisk
Download: http://opensource.dyc.edu/tor-x86_64-ramdisk-downloads
ChangeLog: same as i686.