opensource.dyc.edu

This is the eighth release of Tin Hat. This release concentrates primarily on updating the hardened tool chain, and no changes were made to the kernel since the last release. The system was completely recompiled using hardened Gentoo's stock gcc-4.3.3 plus stack-protection added via the CFLAGS and CXXFLAGS in make.conf. Extensive testing of the most used services and apps gave no issues with the exception of Evolution which required lazy linking.

This is the seventh release of Tin Hat and represents an important turning point for us. As the ISO images start to grow bigger and bigger some decision needed to be made about what to keep and what to drop. The present branch is dedicated to gnome and rather than switching mid stream to some light windowing system, I decided to augment the build process to allow the option of removing documentation under /usr/share/doc, /usr/share/gnome/help and /usr/share/gtk-doc. This reduces the ISOs by approximately 100MB and reduces RAM usage by about three times as much.

I did a study of RAM usage for three different RAM-only systems plus a regular "disk" system for comparison. The purpose of the study was to see what is the best option for Tin Hat. The three systems studied are: 1) the system boots into an initrd (ramdisk), 2) the system boots into an initramfs (ramfs), 3) the system boots into an initramfs, but then sets up a new root on a tmpfs system (ramfs), and finally does a switch_root. The last option is similar to Tin Hat's bootstrapping.

A new release of Tin Hat is out for both i686 and amd64. This is primarily a maintenance release addressing approximately 90 updates and syncing upstream with hardened Gentoo. Some minor bugfixes to the desktop were made. The kernel for amd64 was upgraded to 2.6.26-hardened-r9 but the i686 was held back at 2.6.25-hardened-r13 due to issues with 2.6.26 and 2.6.27. We did not want to wait for those issues to be resolved because the packages were falling behind Gentoo and we did not want to introduce too many security issues.

Cross platform development is difficult and I don't like (re)building toolchains targeted for other architectures. I much prefer a fully featured native environment. In porting tor-ramdisk to the mips, I've worked in uncomfortably restrictive situations, like busybox coreutils with just enough of binutils to be able to compile libraries like zlib and libevent. Much better to have a full blown desktop!

The MIPS port has progressed very nicely since our original venture away from i686 territory onto real routers cpus. The original port was only for a little endian system run in QEMU with binaries statically linked aginst glibc. This broke DNS resolution in busybox and OpenNTP didn't even link. The first task was to migrate to uClibc, thus fixing the broken DNS and time synchronization, and then produce both little and big endian binaries.

This release updates tor to stable 0.2.0.34 to incorporate some security fixes by the Tor team --- see their change log for details. I also took this opportunity to clean up the build scripts which were not modular. Now commands are properly grouped together according to task into bash subroutines. This makes life a lot easier when having to comment out a step. I also backported the modifications to the UI that I wrote for the mips port.

The Tor team release tor 0.2.0.34 on Feb 8, and on the 10th we put together tor-ramdisk 20090217. Tor 0.2.0.34 addresses some security issues which effect exit nodes and directory servers. Tor-ramdisk updates to this version of tor and adds a few new features: The user now has the option to check the time on the system and set the time via rdate in addition to letting ntpd keep synchronization, and when monitoring the system resources the user also gets top information. As with all releases, it is being test in the wild on relay-only node "simba".

This is a minor maintenance update: tor was updated to version 0.2.0.33 and busybox to 1.13.2. As with all releases, this one come tested "in the wild". Tor-relay node "simba" has been running this version with no problems for a week now.

There has been a lot of buzz on the or-talk list about running tor clients/relays/exit nodes in embedded environments like ARM and MIPS boards. For example, Kyle Williams built the JanusPA - An Inline Hardware Privacy Adapter. Plug-n-play devices like these make Tor's anonymity available to the average user which expands the network and makes Tor better able to obfuscate network traffic. Imagine if every cell phone in the world were a Tor relay!