Fun with Productivity!

What a strangely productive weekend. The virtual memory OSes project is essentially finished, even in advance of the original deadline. (Take that, people begging for an extension!) My 590T project is also going nicely, now that most of the code is done.

In a nutshell, my 590T project is modifying Debian packages to include accountability information. The idea is to have a way to identify who was involved in creating the package. This is useful if, for example, a developer’s private key is compromised, which could allow an attacker to introduce malicious code into a package. With accountability information, you could identify which packages were potentially modified and which aren’t.

Ordinary package signing (like Microsoft’s Authenticode) doesn’t work when you don’t have a central authority determining what gets released. And in Debian, the person putting together the source code usually isn’t the same person who compiles it.

The code I’ve written so far modifies the build system so that information about the original source package, all the build dependencies, and the developer doing the compiling are embedded in the resulting packages, in as tamper-resistant a way as is possible without breaking backwards compatibility. Right now it relies on packages being built within a pbuilder environment (essentially a chroot jail with a minimal set of packages installed), which isn’t how the heavy-duty buildds operate, but the principle is the same. Conveniently, I didn’t even need to modify any existing code, since I can do everything I need with the hooks that pbuilder already provides.

Right now I’m recompiling the base packages with accountability information in order to bootstrap an accountable repository. Naturally, this involves writing a script to automate downloading source packages and using pbuilder to compile them. (It’s a poor man’s buildd!) Once I have a decent working set, I can play around with a tool to verify the accountability information in packages.

One potential hangup I’m seeing already is the sheer number of transitive build dependencies most packages have. Even a bare-bones system has a couple dozen packages in it, and the accountability manifest I create needs to note all of them, since any package in the build environment could potentially inject malicious code into a package, a la Reflections on Trusting Trust. It’s quite likely that the number of packages you need to verify will grow exponentially in the search depth.

GCC takes a long time to compile. So does glibc. I don’t know how those Gentoo users can stand compiling everything all the time. Even with a fast computer (which my 933 MHz Pentium III and its 256 MB of memory isn’t) that’s a lot of time spent compiling. It looks like somebody’s computer is going to be running 24/7 compiling packages.

Every time the CPU meter on my desktop drops below 100% I think that glibc might finally be done compiling. It usually just means the build is blocking on I/O for a bit. That tease.

[Fun fact: I can tell when I receive new e-mail by the sound of my hard disk. I'm not kidding.]

2 Responses

  1. Paul;
    Your time spent listening to the RW heads on your HDD, quite frankly, frightens me.

    And I’ll see you in town this week, hopefully. Look me up.


  2. I’ll be there.

Comments are closed.