opensource.dyc.edu

In this release, we take the leap from our old toolchain and adopt Gentoo's hardened-dev overlay which includes all of the hardening features of the previous release, but implemented using the compiler specs rather than using make.conf and other unsavory hacks. The current toolchain is comprised of binutils-2.18-r3, glibc-2.9_p20081201-r4, and gcc-4.4.1-r2. The entire system build just fine with the exception of epiphany which still has to be linked using -z,lazy due to its ugly interrelated libraries.

Andrew Lewman of the tor project asked if some future version of tor-ramdisk could support DHCP. This was an easy enough request. About two weeks ago I edited the setup scripts to allow for one more menu item which invoked busybox's DHCP client, udhcpcd. After a round of debugging I had it ready for i686 and then for the MIPS port. After running on Simba for over a week, its time for their release: the i686 release is named 20090926 and the MIPS port is 20090927. Hmm ... perhaps I should use some other versioning scheme!

I'm a day late in announcing it, but here's the MIPS port of the 20090821 release. Tor and busybox were similarly updated but the kernel needed reconfiguring to allow for the FILE_LOCKING feature which the tor-0.2.1.x branch makes use of. This in turn required block devices to be enabled in the kernel which a pure ram image doesn't necessarily need, and we didn't have im place when we were working with the 0.2.0.x branch.

Both the little and big endian QEMU images were tested as well as atheros image. Tor node "mufusa" is currently running the later image on a Mikrotik 433AH board.

The tor team recently moved their stable branch from tor 0.2.0.x to 0.2.1.x which introduced many feature improvements and bug fixes --- see their changelog. The new codebase, however, revealed a bug in the stack smashing protector (SSP) of gentoo's stock hardened compiler gcc-3.4.6 --- see tor bug #1060.

This is perhaps our tightest release yet. While the kernel remained stable at hardened-2.6.28 (a minor bump from -r7 to -r9), we concentrated further on improving the toolchain. After painstakingly wading through a sea of binaries, figuring out what breaks and what doesn't with various toolchain hardening, we able to apply -fstack-protector-all -D_FORTIFY_SOURCE=2 -fPIC -fPIE to cc1, and -pie, -now, -relro to the linker in producing all of our libraries and binaries. Trouble only came from glibc and evolution.

This release is the MIPS port equivalent of the 20090627 i686 release in which we updated tor to 0.2.0.35, the latest stable version sporting some major bug fixes. Updates and changes to busybox, ntpd and the setup scripts also came over with no differences and the build scripts only needed minor editing. We tested both little and big endian QEMU images for several days each (as node Mufasa) before switching to the Mikrotik rb433ah board.

Speak of the devil and he appears! When I last posted that stable tor has been sitting at 0.2.0.34 since February, I had no idea 0.2.0.35 was right around the corner! The announcement came on or-talk@freehaven.net just the next day. It was a minor effort to edit the build script and incorporate the lastest stable version in the next release of tor-ramdisk.

The stable branch of tor, tor-0.2.0.34 has been around since February, so there hasn't been any need to update tor-ramdisk for i686. However, there has been some progress in the kernel --- new NIC chipsets are available --- and busybox has also come out with a new release 1.14.1, but this is not a critical because non of the new features are needed.

If you've been following the news you may already know that tor is being used to circumvent the Iranian firewalls and protect the identity of protesters. Here's two sites http://iran.whyweprotest.net and http://torir.org.

One point that came up on or-talk@freehaven.net is that we need to run bridges --- bridges are relays not listed in the public directory and so are not easily firewalled out. If anyone is running a relay you might consider running