The Threat Bruce Schneier s blog post about the Mariposa Botnet has an interesting discussion in the comments about how to make a secure system [1]. Note that the threat is considered to be remote attackers, that means viruses and trojan horses which includes infected files run from USB devices (IE you aren t safe just because you aren t on the Internet). The threat we are considering is not people who can replace hardware in the computer (people who have physical access to it which includes people who have access to where it is located or who are employed to repair it). This is the most common case, the risk involved in stealing a typical PC is far greater than the whatever benefit might be obtained from the data on it a typical computer user is at risk of theft only for the resale value of a second-hand computer. So the question is, how do can we most effectively use free software to protect against such threats? The first restriction is that the hardware in common use is cheap and has little special functionality for security. Systems that have a TPM seem unlikely to provide a useful benefit due to the TPM being designed more for Digital Restrictions Management than for protecting the user and due to TPM not being widely enough used. The BIOS and the Bootloader It seems that the first thing that is needed is a BIOS that is reliable. If an attacker manages to replace the BIOS then it could do exciting things like modifying the code of the kernel at boot time. It seems quite plausible for the real-mode boot loader code to be run in a VM86 session and to then have it s memory modified before it starts switches to protected mode. Every BIOS update is a potential attack. Coreboot replaces the default PC BIOS, it initialises the basic hardware and then executes an OS kernel or boot loader [2] (the Coreboot Wikipedia page has a good summary). The hardest part of the system startup process is initialising the hardware, Coreboot has that solved for 213 different motherboards. If engineers were allowed to freely design hardware without interference then probably a significant portion of the computers in the market would have a little switch to disable the write line for the flash BIOS. I heard a rumor that in the days of 286 systems a vendor of a secure OS shipped a scalpel to disable the hardware ability to leave protected mode, cutting a track on the motherboard is probably still an option. Usually once a system is working you don t want to upgrade the BIOS. One of the payloads for Coreboot is GRUB. The Grub Feature Requests page has as it s first entry Option to check signatures of the bootchain up to the cryptsetup/luksOpen: MBR, grub partition, kernel, initramfs [3]. Presumably this would allow a GPG signature to be checked so that a kernel and initrd would only be used if they came from a known good source. With this feature we could only boot a known good kernel. How to run User Space The next issue is how to run the user-space. There has been no shortage of Linux kernel exploits and I think it s reasonable to assume that there will continue to be a large number of exploits. Some of the kernel flaws will be known by the bad guys for some time before there are patches, some of them will have patches which don t get applied as quickly as desired. I think we have to assume that the Linux kernel will be compromised. Therefore the regular user applications can t be run against a kernel that has direct hardware access. It seems to me that the best way to go is to have the Linux kernel run in a virtual environment such as Xen or KVM. That means you have a hypervisor (Xen+Linux or Linux+KVM+QEMU) that controls the hardware and creates the environment for the OS image that the user interacts with. The hypervisor could create multiple virtual machines for different levels of data in a similar manner to the NSA NetTop project, not that this is really a required part of solving the general secure Internet terminal problem but as it would be a tiny bit of extra work you might as well do it. One problem with using a hypervisor is that the video hardware tends to want to use features such as bus-mastering to give best performance. Apparently KVM has IOMMU support so it should be possible to grant a virtual machine enough hardware access to run 3D graphics at full speed without allowing it to break free. Maintaining the Virtual Machine Image Google has a good design for the ChromiumOS in terms of security [4]. They are using CGroups [5] to control access to device nodes in jails, RAM, CPU time, and other resources. They also have some intrusion detection which can prompt a user to perform a hardware reset. Some of the features would need to be implemented in a different manner for a full desktop system but most of the Google design features would work well. For an OS running in a virtual machine when an intrusion is detected it would be best to have the hypervisor receive a message by some defined interface (maybe a line of text printed on the console ) and then terminate and restart the virtual machine. Dumping the entire address space of the virtual machine would be a good idea too, with typical RAM sizes at around 4G for laptops and desktops and typical storage sizes at around 200G for laptops and 2T for new desktops it should be easy to store a few dumps in case they are needed. The amount of data received by a typical ADSL link is not that great. Apart from the occasional big thing (like downloading a movie or listening to Internet radio for a long time) most data transfers are from casual web browsing which doesn t involve that much data. A hypervisor could potentially store the last few gigabytes of data that were received which would then permit forensic analysis if the virtual machine was believed to be compromised. With cheap SATA disks in excess of 1TB it would be conceivable to store the last few years of data transfer (with downloaded movies excluded) but such long-term storage would probably involve risks that would outweigh the rewards, probably storing no more than 24 hours of data would be best. Finally in terms of applying updates and installing new software the only way to do this would be via the hypervisor as you don t want any part of the virtual machine to be able to write to it s data files or programs. So if the user selects to install a new application then the request please install application X would have to be passed to the hypervisor. After the application is installed a reboot of the virtual machine would be needed to apply the change. This is a common experience for mobile phones (where you even have to reboot if the telco changes some of their network settings) and it s something that MS-Windows users have become used to but it would get a negative reaction from the more skilled Linux users. Would this be Accepted? The question is, if we built this would people want to use it? The NetTop functionality of having two OSs interchangeable on the one desktop would attract some people. But most users don t desire greater security and would find some reason to avoid this. They would claim that it lowered the performance (even for aspects of performance where benchmarks revealed no difference) and claim that they don t need it. At this time it seems that computer security isn t regarded as a big enough problem for users. It seems that the same people who will avoid catching a train because one mugging made it to the TV news will happily keep using insecure computers in spite of the huge number of cases of fraud that are reported all the time.

• [1] http://www.schneier.com/blog/archives/2010/03/mariposa_botnet.html
• [2] http://www.coreboot.org/Welcome_to_coreboot
• [3] http://grub.enbug.org/FeatureRequests
• [4] http://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs/system-hardening
• [5] http://lxr.linux.no/linux+v2.6.30/Documentation/cgroups/

In a comment on my post Shared Objects and Big Applications about memlockd [1] mic said that they use memlockd to lock the entire root filesystem in RAM. Here is a table showing my history of desktop computers with the amounts of RAM, disk capacity, and CPU power available. All systems better than a 386-33 are laptops a laptop has been my primary desktop system for the last 12 years. The columns for the maximum RAM and disk are the amounts that I could reasonably afford if I used a desktop PC instead of a laptop and used the best available technology of the day I m basing disk capacity on having four hard drives (the maximum that can be installed in a typical PC without extra power cables and drive controller cards) and running RAID-5. For the machines before 2000 I base the maximum disk capacity on not using RAID as Linux software RAID used to not be that good (lack of online rebuild for starters) and hardware RAID options have always been too expensive or too lame for my use.

Year	CPU	RAM	Disk	Maximum RAM	Maximum Disk
1988	286-12	4M	70M	4M	70M
1993	386-33	16M	200M	16M	200M
1998	Pentium-M 233	96M	3G	128M	6G
1999	Pentium-2 400	256M	6G	512M	40G
2000	Pentium-2 600	384M	10G	512M	150G
2003	Pentium-M 1700	768M	60G	2048M	400G
2009	Pentium-M 1700	1536M	100G	8192M	4500G
2010	Core 2 Duo T7500 2200	5120M	100G	8192M	6000G

The above graph shows how the modern RAM capacities have overtaken older disk capacities. So it seems that a viable option on modern systems is to load everything that you need to run into RAM. Locking it there will save spinning up the hard drive on a laptop. With a modern laptop it should be possible to lock most of the hard drive contents that are regularly used (IE the applications) into RAM and run with /home on a SD flash storage device. Then the hard drive would only need to be used if something uncommon was accessed or if something large (like a movie) was needed. It also shows that there is potential to run diskless workstations that copy the entire contents of their root filesystem when they boot so that they can run independently of the server and only access the server for /home. Note that the size of the RAM doesn t need to be larger than the disk capacity of older machines (some of the disk was used for swap, /home, etc). But when it is larger it makes it clear that the disk doesn t need to be accessed for routine storage needs. I generated the graph with GnuPlot [2], the configuration files I used are in the directory that contains the images and the command used was gnuplot command.txt . I find the GnuPlot documentation to be difficult to use so I hope that this example will be useful for other people who need to produce basic graphs I m not using 1% of the GnuPlot functionality.

• [1] http://etbe.coker.com.au/2009/12/19/shared-objects-and-big-applications/
• [2] http://www.gnuplot.info/

I just updated to the latest beta of Chrome, and the backspace key stopped working as a keyboard shortcut for the Back button. After a few times of stabbing the backspace key and not getting the result I wanted, I decided to go looking into what was going on here. It looks like it all started with bug 30699, where someone didn't like the default behaviour. That led to bug 36533, when the people (like me) noticed the functionality they were relying on disappeared. Now I fully understand that Backspace == Back is not the default behaviour of Firefox (on Linux), but it is a configurable option, and I'd had it enabled there for years. I think it all started with when I migrated from Windows to Linux. It's normal for Backspace == Back with IE and I think Firefox for Windows, and I've just developed the muscle memory for it, and I've never had a problem like what the submitter of bug 30699 was complaining about. I look forward to it becoming a configurable option in Chrome.

I and Rafael Cunha de Almeida got together today with the purpose of closing as much RC-bugs in Debian as we could. I must say it was better than what I d expect. We started with #570348 . This bug was introduce with an upload that tried to fix #569586 which, in turn, was related to a change in libc6. It would be easy to introduce an ifdef in the code but, as we tried to read and understand the code, we didn t see the need of the function that was causing the problem. It seems to make the same thing as alphasort from dirent.h, with the disadavantage that it was not locale-sensitive. So we removed the customized alphasort and made it use the library one. Then we headed to the strange #504947. As the maintainer didn t seem satisfied with the new patch system introduced by the last NMU, we simply made a patch that removes the patch system and applies the patch directly in .diff.gz. Hope it helps. Searching for another thing to work, we noticed that #571791 was not happening in my box, and asked if anyone could reproduce it. So we found #571748. The first thing about this bug we noticed is that its package causes a division by 0 error in popcon, which made us report a bug about it. We thought that this was a sign that the package was not widely used. Anyway, we decided to fix this bug, which was very fun indeed! After a lot of trials, some succesful, some not, we got to a very simple and nice patch, which was submitted. We also submited other bugs to the same package, that we found while using it. It s a cool package, you should try it out to avoid that division by 0 in popcon.

After fixing some bugs this week, I ve noticed they ve been one per day (on average) so I think I m joining Stefano Zacchiroli on this RCBW thingie let s see if I can keep up! These are this week s bugs: #561645 gdesklets Doesn t work with python2.6 (thanks to Andrew Starr-Bochicchio)
#571488 gedit FTBFS with Python 2.6 as default
#571517 totem FTBFS with Python 2.6 as default
#571510 rhythmbox FTBFS with Python 2.6 as default
#533836 spe FTBFS with Python 2.6 as default
#569378 gnet FTBFS
#551215 gtkmm-documentation FTBFS I ve also sponsored gnome-dvb-daemon for Sebastian Reichel, which fixes two more RC bugs: #566949 gnome-dvb-daemon FTBFS with Python 2.6 as default
#569480 gnome-dvb-daemon FTBFS It s interesting to note that all of the above bugs except for the spe one are from pkg-gnome packages. We still have a few more, although they are the hard ones so it s not gonna be that easy for the next week

I must confess I don't remember who I got this invitation from. Anyway, if you are in the right geographic area, you might be interested. I will try to participate: This is a year-long seminar that will be held the second Thursday every month at Fonoteca Nacional (a place I have wanted to visit for a long time!), in Barrio de Santa Catarina, Coyoac n. Among the organizers they have Creative Commons Mexico. Free entrance (but limited space - so they ask interested people to confirm their presence by mail to bvallarta@conaculta.gob.mx). [update] I went with Pooka to the first session. We arrived almost 1hr late (due to me mistaking the schedule :-/ ) but it was interesting. Of course, quite biased towards the Google viewpoints, but interesting. We got the program for the next sessions So, mostly for myself to keep handy, here it goes:

Date	Title	Speakers
2010-03-11	Google and copyright	Manuel Tamez, Hugo Contreras, Mar a Fernanda Mendoza
2010-04-08	Generalities about rights on intelectual property	Jes s Parets, Guillermo Sol rzano, Jorge Mier y Concha
2010-05-13	Copyright's nature and competent authorites	Carmen Arteaga, Luis Schmidt, C sar Callejas
2010-06-10	Moral and patrimonial rights	Guillermo Pous, Eduardo de la Parra, Ram n Ob n
2010-07-08	Reproduction rights for audible material	lvaro Hegewisch, scar Javier Solorio, Marco Antonio Morales, Jos Ram n C rdeno
2010-08-12	Licenses and patrimonial right transmission. Works for hire, works done under laboral relationship, or carried out in official service	Dolores Franco, Jes s Mej a, Ra l Pastor
2010-09-09	Limits to explotation rights and literary plagiarism	Carmen Arteaga, Juan Ram n Ob n, Jorge Mier y Concha, C sar Callejas
2010-10-14	Copyright in a digital setting	Jes s Parets, Gast n Esquivel
2010-11-11	Law-regulated intelectual property rights	Rosalba Elizalde, Salvador Ortega, Gast n Esquivel, Manrique Moheno
2010-12-09	International protection and collective gestive societies	Horacio Rangel, Luis Schmidt, Jes s Mej a

After quite some time (last release 01-04-2009), hdapsd got a bit of love.
Brice Arnould has contributed some code for Hewlett-Packard laptops (those supported by the hp_accel module, see drivers/hwmon/hp_accel.c) and I finally crossed all lines and wrote support for Apple MacBooks (the Intel ones, via applesmc module, see drivers/hwmon/applesmc.c).

The HP code is interesting, as it support a hardware-logic mode, where hdapsd only parks the heads when told so by the HP hardware. As I do not own any compatible hardware, this is only tested by Brice himself.
The Apple SMC code isn't tested at all, as I don't have the hardware either.

That's why I want YOU to test it further (both, on HP and Apple) and report me bugs (mail to evgeni@debian.org preferred) if you find any :)

You can get the latest source either via git from github:

git clone -b new-interfaces git://github.com/evgeni/hdapsd.git

Or from githubs tarball generator: http://github.com/evgeni/hdapsd/tarball/eb711f30395ac9bc682b14c22d8445b7ddf0b4a0

After you got the source, a simple

./autogen.sh

make

should produce a src/hdapsd binary, that you can test.

I can provide Debian and Ubuntu .debs if needed too.

Daniel, I also recently installed a WRT on the Linksys WRT54GL. But I used DD-WRT instructions went to http://www.dd-wrt.com/site/support/router-database, entered my model number and got direct download links to the firmware along with a README. One very important points in flashing these routers is to clear the NVRAM by doing a hard reset BEFORE and AFTER an upgrade to a different type of software on the device. Also, starting with a micro build is strongly recommended. In any case the hardware looks to be very solid, especially if you don t need gigabit ethernet and n wireless, but might need some advanced networking features.

I finally got a few hours free this morning to check an item off my home system administration checklist: upgrading the wireless router's firmware to OpenWRT. There were a couple motivations for this, including the fact that my SoundBridge Radio couldn't maintain a connection to my firefly server using the built-in firmware, and I had read that OpenWRT would work better. Since this is posted on Planet Debian, I should mention why I didn't use DebianWRT. The basic answer is this text at the top of the DebianWRT homepage:

Currently the most common methods used to run Debian on these systems is to install OpenWRT or a similar firmware, add disk space either by USB storage or NFS, create a debian chroot by either running cdebootstrap from inside OpenWRT or debootstrap --foreign on a PC, and running Debian from this chroot. For example, instructions for the WLHDD.

I'm not sure whether this is because DebianWRT is experimental, or because its goal is to use routers as cheap general computers. Either way, it sounds way too complicated and/or fragile for what I'm interested in (i.e., a wireless router with better software). The goal here is to get something that does a better job than the built-in WRT firmware, but doesn't require too much tinkering to get working or to maintain. I have plenty of outlets for my tinkering urges already. Nothing here was exactly difficult, but it was hard to find all the information I needed to get things working. Hopefully documenting the steps I went through here will save someone else some time. Step 1: acquire the firmware This was trickier than you might think. If you click on the download link at the OpenWRT web site, you end up at the top of an FTP server populated with a vast quantity of stuff. Worse, when you find the actual firmware images, you'll quickly discover that there are piles and piles of them divided between sixteen directories, and no guidance as to which one to pick. And picking the wrong one will turn your beautiful router into a doorstop. Luckily, the OpenWRT documentation contains a section called "Getting Started". Unluckily, that section consists of the following text:

1.1 Getting started 1.1.1 Installation 1.1.2 Initial configuration 1.1.3 Failsafe mode

Whoops, someone forgot to execute on a TODO. Undeterred, I consulted the usual fallback reference, Google. It pointed me at several references, some of which were hidden on other parts of the OpenWRT site. Armed with these, I was able to determine that:

1. My WRT54GL v1.1 probably uses a Broadcom 5352 chipset.
2. The correct firmware, according to multiple sources, is probably in the kamikaze top-level director, the latest version's subdirectory, and the bcrm-2.4 directory under the version (the link is to 8.09.2, which is current as of March 6, 2010). Apparently the bcrm47xx directory doesn't have wireless support; it helpfully contains a file called NO-BROADCOM-WIRELESS to warn you off, but unhelpfully doesn't include any additional information in that file (like what exactly is broken or that you can find a working firmware in a sibling directory) ... oh well.
3. The firmware file that you want is openwrt-wrt54g-squashfs.bin, even though it doesn't match the model number of the router. This directory could use a README file explaining which hardware is supported by each of the dozen or so firmware files it contains.

Step 2: install the firmware After Step 1, this was a real relief. I just used the built-in Linksys firmware installer, pointed it at the .bin file, and it went. Step 3: configure the router The installation guide I followed was pretty much silent about what to do after I got the firmware on. Luckily, this is just a software problem, meaning it's much more familiar territory for me.

1. First things first: I checked that I could still get a DHCP lease. It worked.
2. Armed with that, I tried telneting to the router. I used the resulting root prompt to set a password on the root account.
3. I logged out and tried telneting in. Apparently the router is configured to disallow root logins over telnet if you don't have a password. Good for them (although why allow telnet at all?); oops for me.
4. Luckily, an ssh server was installed by default. I like using keys to log in, so I tracked down the documentation on configuring the server to use public-key authentication; it turns out there's a single global key file named /etc/dropbear/authorized_keys that's exactly like OpenSSH's per-user authorized_keys file. No idea what would happen if I had multiple users, but I won't.
5. The next obstacle: I didn't have an Internet connection. For some reason, my cable modem didn't want to give the router a DHCP lease. On the off-chance that it was remembering too much, I rebooted it and ran ifup wan. That fixed the problem. I still don't know why.
6. Not a step, but a useful note: in the process of figuring the above out, I found readlog. It's basically dmesg for syslog files; it shows the most recent lines written to syslog. This is useful because there isn't a real syslog file, due to the fact that there would be no room to store it on the 54GL.
7. Finally, I had to get wireless working. The documentation is very helpful when it comes to describing the syntax of the wireless configuration. Unfortunately, I read the list of encryption options and missed the section right below where their meanings are explained (although, to be honest, I might not have understood the implications of the explanation without the research I did anyway).

   option encryption none, wep, psk, psk2, wpa, wpa2

   I wanted WPA2 encryption, so I entered wpa2. And nothing worked. After a good hour of trying different options on the client, swapping software components in and out on the router, experimenting with the encryption key syntax, and crawling Google, I finally found my answer. If you just want WPA2 encryption, you must not use wpa2 as the encryption type. Instead, use psk2. It turns out out that wpa2 actually means use WPA2 and also use an external RADIUS server for authentication. psk2 is the system you're familiar with from a typical consumer wireless router.

Step 4: enjoy And with that, it works. Unfortunately, contrary to what I wrote here originally, my Roku still doesn't work. On the other hand, having a real Linux installation is helpful for debugging it. Currently my suspicion is that the router isn't passing multicast packets between the wired and wireless interfaces (broadcast works fine, multicast doesn't). That said, it seems like if I restart Firefly just before I start playing music, I can play reasonably reliably -- as long as I don't stop, because if I do, the Roku forgets that the music server is there. Either way, I've spent about as much time fighting this as I can afford. One lingering worry I have is security; unlike Debian, which has both a security mailing list and tools to inform me when I need to install a security update, the OpenWRT firmware doesn't seem to have any mechanism for distributing security notices. True, there is an openwrt-security-announce list, but it appears to be entirely unused, as is openwrt-announce. Something to keep an eye on, then. Also (file under note to self), I need to remember to verify that the router isn't exposing services to the outside world. The default iptables configuration is hideously complex; with just a quick glance, it could be setting up a floral shop for all I can tell. I'll need to test this empirically and maybe analyze the rules in more depth.

Quite surprisingly, I ll attend the Chemnitzer Linuxtage 2010 in Eastern Germany. This is a happenstance, I managed to get fast transportation (via my boss) and accomodation (in a hotel). I will try to help staffing the booth of Debian this time (so I cannot be called Traitor any longer). Schedule, due to the spontaneousness of this, no, though. I may not even be there on Sunday, dunno No RCBD (or night) though, some real life and a new release (with fix of an FTBFS-on-hurd-i386 bug) though:
RMD160 (/MirOS/dist/mir/makefs/makefs-20100306.tar.gz) = f65bd8ef5cf3306a9112587dd4915b6255e479fe
This version pulls in NetBSD changes (Acorn Archimedes support, for one), but I ve also coded support for boot-info-table (J rg compatible), as well as setting the PVD dates (used by GNU GRUB 2 for UUID s). On MirBSD, cdio(1) can now be used to burn (TAO) and blank (quick) CD-RW media (I backported some OpenBSD changes) too.

The kitchen renovations are slooowly progressing. Running away to New York for a week certainly helped. The cabinets arrived on Monday, and our contractor started installation on Wednesday. Templating for the counter tops is supposed to happen on Monday, and then it apparently takes a couple of weeks for the stone to get cut to size. So much for this whole thing only taking a couple of weeks :-( I expect the overhead cabinets can be installed once the templating is done (that's something I need to check with the contractor today). It's very exciting to see the kitchen start to take shape. I'm dying to be able to actually use it. Photos of the progress so far are here

Tomorrow is the day for Paris half-marathon, the mass half-marathon that is traditionnally run 4-5 weeks before Paris marathon. This year, I'll run both, so tomorrow, I'll be running in Paris (and Bois de Vincennes) streets...along with 27,000 other people..., attempting to beat my 1h43'55" record set in my last (and as of now) only half-marathon, one month ago, in Bullion. That might be hard as running at one's own pace is easier in a run with 1,000 runners..:-) Ralf Treinen told me he might show up around km 7 (place de l'H tel de Ville). I should be around there around 11h50 as the start is at 10h and I should probably cross the start line at about 10h15, then run 5mins/km. So, if you're around eastern Paris and wake up "early" on Sundays, feel free to come and show me a nice Debian swirl so that I can run even faster (or less slow). I'll be wearing a black top with short sleeves and short running pants (not the easies to spot, I admit). Then try spotting Ralf and have a beer..:-).

OCaml Batteries Included 1.1.0 has arrived in Debian I've just uploaded the Debian package of OCaml Batteries Included 1.1.0 to the Debian unstable archive; hopefully, it will quickly enter testing to be released with the next Debian stable release. This is the first release in Debian of the "new generation" of Batteries Included, which has followed a strict diet, and now has Camomile as its only external dependency. It took me a while to package it due to an intertwining transition to OCaml 3.11.2 (during which we have fleshed out the last remaining few bits of transition to our new dependency system). Also, I had to fix some typical build issue with upstream, which kindly coordinated with me to have the fixes included in 1.1.0. So go, enjoy Batteries 1.1.0, and let me know your feedback:

    # apt-get install ocaml-batteries-included

(check that it will install 1.1.0 though, it might take a few days to hit your favorite architecture and mirror) Tip: starting from this version you will need the following to use Batteries in place of the legacy standard library in your sources:

    open Batteries_uni

for multi-threaded programs you should rather use open Batteries. Check the FAQ file installed under /usr/share/doc/libbatteries-ocaml-dev/ for more quick start information.

You have a gitolite install on host $MASTER, and you want a mirror on $SLAVE. Here is one way to do that. $CLIENT is your workstation, that need not be the same as $MASTER or $SLAVE.

1. On $CLIENT, install gitolite on $SLAVE. It is ok to re-use your gitolite admin key here, but make sure you have both public and private key in .ssh, or confusion ensues. Note that when gitolite asks you to double check the "host gitolite" ssh stanza, you probably want to change hostname to $SLAVE, at least temporarily (if not, at least the checkout of the gitolite-admin repo will fail) You may want to copy .gitolite.rc from $MASTER when gitolite fires up an editor.
2. On $CLIENT copy the "gitolite" stanza of .ssh/config to gitolite-mirror to a stanza called e.g. gitolite-slave fix the hostname of the gitolite stanza so it points to $MASTER again.
3. On $MASTER, as gitolite user, make passphraseless ssh-key. Probably you should call it something like 'mirror'
4. Still on $MASTER. Add a stanza like the following to $gitolite_user/.ssh/config

    host gitolite-mirror
      hostname $SLAVE
      identityfile ~/.ssh/mirror
   

   run ssh gitolite-mirror at least once to test and set up any "know_hosts" file.
5. On $CLIENT change directory to a checkout of gitolite admin from $MASTER. Make sure it is up to date with respect origin

   git pull
   

6. Edit .git/config (or, in very recent git, use git remote seturl --push --add) so that remote origin looks like

   fetch = +refs/heads/*:refs/remotes/origin/*
   url = gitolite:gitolite-admin
   pushurl = gitolite:gitolite-admin
   pushurl = gitolite-slave:gitolite-admin
   

7. Add a stanza

   repo @all
     RW+     = mirror
   

   to the bottom of your gitolite.conf Add mirror.pub to keydir.
8. Now overwrite the gitolite-admin repo on $SLAVE git push -f Note that empty repos will be created on $SLAVE for every repo on $MASTER.
9. The following one line post-update hook to any repos you want mirrored (see the gitolite documentation for how to automate this) You should not modify the post update hook of the gitolite-admin repo. git push --mirror gitolite-mirror:$GL_REPO.git
10. Create repos as per normal in the gitolite-admin/conf/gitolite.conf. If you have set the auto post-update hook installation, then each repo will be mirrored. You should only push to $MASTER; any changes pushed to $SLAVE will be overwritten.

Yay! The ticket is ready, and the long trip is getting closer. Long trip? Won't most Debianers have a longer trip than me this time? Nope, not by far My University will be on vacations starting July 3, and it is three weeks before DebConf... So I will be travelling Southwards before :-) Details will follow later. Suffice to say that I am more than happy to announce that... I am definitively going to DebConf10!

After weeks of trying to get around to doing that, I am finally starting the process of replacing my 10-year old 1024 bits DSA key with a shiny new 4096 bits RSA key. The old key ID is F5D65169, the new key ID is FA1E5292; it s available from the keyservers or my website. I have put up a transition document, signed with both keys; if you ve signed my old key, grab it, verify it and if all is OK on your end, please sign the new key. You ll notice that one of the old UIDs did not make it to the new key; that s because I m not using that email address and don t actually intend to use it in the future. Thanks!

Global trends For some time I have been trying to pinpoint what it is that is brewing in Italy and risks spreading elsewhere, like it happened in the past. I don't need to be decent to stay in power While following a train of thought during a political/philosophical lecture I figured that a current growing trend is to have public figures that are more and more indecent. In Italy it is very hard to find a public figure you can look up to. It is hard to name a politician that is not involved in some shady exchange of favours or some abues of their powers, and we got used to seeing people in power implicated in major corruption scandals, perverted prostitution affairs, or dealings with international criminal organisations. They do not normally end up in jail, and in fact they keep being very firmly in power, because they manage to stretch or change the laws to get away, or at least to delay trials in order to trigger some statute of limitations. Is there a pattern here that, although maybe not as clearly defined as in Italy, can be found more or less globally? Yesterday I thought that this could be such a pattern:

I don't need to be decent to stay in power

If I think of it like that, then it is most definitely not just an Italian phenomenon. If you tell "one doesn't need to be decent to stay in power" to a British, or to a French, I would not expect them to see anything strange with it. We all find it depressing, but we are all used to it. It is a pattern with repercussions, though: once that becomes normal in a society, it means that people who get to be in power are free to abuse their power much as they want, as long as they are careful enough not to end up in jail. Because, well, nowadays one doesn't need to be decent to stay in power. I don't need to follow the law to stay in power That first pattern is already quite well accepted in Italy. So much well accepted, that I think we are starting to see what comes next. At the end of March we are going to have elections for some regional governors. Funnily enough, in Lazio, the very important region around Rome, the centre-right coalition failed to submit the paperwork on time, and is out of the elections. It is not just red tape: at some point someone will have to print out the ballots and dispatch them to the voting booths, so one expects to have the coalition logos and the names of the candidates submitted in time, together with signatures supporting the candidates and whatever else the election process needs. Well, they missed the deadline, they got there after closing time and the building was, well, closed. It was a fantastic opportunity for a laugh. Memes blossomed on the Italian intarwebs and we now have 2 or 3 new expressions to mean "stupid". However, now it's hard to tell what is going to happen. On one hand, you can't exclude one of the two major coalitions because of some bureaucratic detail like an office closing time. But on the other hand, several minor coalitions have been excluded in all sorts of past elections because of similar things, and it really would not be fair to start making exceptions now. But Lombardia, the region around Milan and Emilia Romagna, the one around Bologna, both very, very important, are having similar kinds of problems. In both regions the previous governors are running again, for the 3rd time in a row, and most likely they legally can't do it, and if elected one can sue and force them to resign, because they have been in power long enough. Lots of paper is being shuffled at the moment to figure if they can get away with it or not. Oh, and the lawyers of the candidate for the Milan region also managed to get to the tribunal after closing time, but apparently there was still someone inside and they managed to shout loud enough, or somesuch. Anyway, the situation is getting hot. The Lazio coalition that has been excluded because of their incompetence is now hard at work pushing their potential voters to mount a fracas. Chances are that eventually they'll get away with it, and manage to take part to the election. If that happens, they will likely get close to winning it. So this seems to be a new pattern that is emerging:

I don't need to follow the law to stay in power

Which, again, is a pattern with quite some repercussions. It is something much more radical than just an issue with morality: it means feudalism, it means we are culturally ready to accept dictatorship. So, please do me a favour: do not think for a moment that Italy is just a funny place with lemons and tomatoes, and watch out for these patterns emerging around you.

The Opera-Mini Dispute I have just read an interesting article about the Opera browser [1]. The article is very critical of Opera-Mini on the iPhone for many reasons most of which don t interest me greatly. There are lots of technical trade-offs that you can make when designing an application for a constrained environment (EG a phone with low resolution and low bandwidth). What does interest me is the criticism of the Opera Mini browser for proxying all Internet access (including HTTPS) through their own servers, this has been getting some traction around the Internet. Now it is obvious that if you have one server sitting on the net that proxies connections to lots of banks then there will be potential for abuse. What apparently isn t obvious to as many people is the fact that you have to trust the application. Causes of Software Security Problems When people think about computer security they usually think about worms and viruses that exploit existing bugs in software and about Trojan horse software that the user has to be tricked into running. These are both significant problems. But another problem is that of malicious software releases. I think that this is significantly different from Trojan horses because instead of having an application which was written for the sole purpose of tricking people (as is most similar to Greek history) you have an application that was written by many people who genuinely want to make a good product but you have a single person or small group that hijacks it. Rumor has it that rates well in excess of $10,000 are sometimes paid for previously unknown security vulnerabilities in widely used software. It seems likely that a programmer who was in a desperate financial situation could bolster their salary by deliberately putting bugs in software and then selling the exploits, this would not be a trivial task (making such bugs appear to be genuine mistakes would take some skill) but there are lots of people who could do it and plausibly deny any accusation other than carelessness. There have been many examples of gambling addicts who have done more foolish things to fund their habit. I don t think it s plausible to believe that every security flaw which has been discovered in widely used software was there purely as the result of a mistake. Given the huge number of programmers who have the skill needed to deliberately introduce a security flaw into the source of a program and conceal it from their colleagues I think it s quite likely that someone has done so and attempted to profit from it. Note that even if it could be proven that it was impossible to profit from creating a security flaw in a program that would not be sufficient to prove that it never happened. There is plenty of evidence of people committing crimes in the mistaken belief that it would be profitable for them. Should We Trust a Proprietary Application or an Internet Server? I agree with the people who don t like the Opera proxy idea, I would rather run a web browser on my phone that directly accesses the Internet. But I don t think that the web browser that is built in to my current smart-phone is particularly secure. It seems usual for a PC to need a security update for the base OS or the web browser at least once a year while mobile phones have a standard service life of two years without any updates. I suspect that there is a lot of flawed code running on smart phones that never get updated. It seems to me that the risks with Opera are the single point of failure of the proxy server in addition to the issues of code quality while the risks with the browser that is on my smart-phone is just the quality of the code. I suspect that Opera may do a better job of updating their software to fix security issues so this may mitigate the risk from using their proxy. At the moment China is producing a significant portion of the world s smart-phones. Some brands like LG are designed and manufactured in China, others are manufactured in China for marketing/engineering companies based in Europe and the US. A casual browse of information regarding Falun Gong makes the character of the Chinese leadership quite clear [2], I think that everything that comes out of China should be considered to be less trustworthy than equivalent products from Europe and the US. So I think that anyone who owns a Chinese mobile phone and rails against the Opera Mini hasn t considered the issue enough. I don t think it s possible to prove that an Opera Mini with it s proxy is more or less of a risk than a Chinese smart-phone. I m quite happy with my LG Viewty [3] but I wouldn t use it for Internet banking or checking my main email account. Also we have to keep in mind that mobile phones are really owned by telephone companies. You might pay for your phone or even get it unlocked so you can run it on a different network, but you won t get the custom menus of your telco removed. Most phones are designed to meet the needs of telcos not users and I doubt that secure Internet banking is a priority for a telco. Update: You can buy unlocked mobile phones. But AFAIK the Android is the only phone which might be described as not being designed for the needs of the telcos over the needs of the users. So while you can get a phone without custom menus for a telco, you probably can t get a phone that was specifically designed for what you want to do. The Scope of the Problem Mobile phones are not the extent of the problem, I think that anyone who buys a PC from a Chinese manufacturer and doesn t immediately wipe the hard drive and do a fresh OS install is taking an unreasonable risk. The same thing goes for anyone who buys a PC from a store where it s handled by low wage employees, I can imagine someone on a minimum income accepting a cash payment to run some special software on every PC before it goes out the door that wouldn t be any more difficult or risky than the employees who copy customer credit card numbers (a reasonably common crime). It s also quite conceivable that any major commercial software company could have a rogue employee who is deliberately introducing bugs into it s software. That includes Apple. If the iPhone OS was compromised before it shipped then the issue of browser security wouldn t matter much. I agree that having the minimum possible number of potential security weak points is a good idea. They should allow Opera Mini users to select that HTTPS traffic should not be proxied. But I don t think that merely not using a proxy would create a safe platform for Internet banking. In terms of mobile phones most things are done in the wrong way to try and get more money out of the users. Choose whichever phone or browser you want and it will probably still be a huge security risk. Harald Welte is doing some really good work on developing free software for running a GSM network [4]. But until that project gets to the stage of being widely usable I think that we just have to accept a certain level of security risk when using mobile phones.

• [1] http://counternotions.com/2010/02/18/mini/
• [2] http://www.faluninfo.net/
• [3] http://etbe.coker.com.au/2009/05/31/lg-u990-viewty/
• [4] http://laforge.gnumonks.org/weblog/2010/02/13/#20100213-six_weeks_to_bcch

During recent weeks, not only sbuild and buildd were changed, but also wanna-build. Many changes were small and don't have direct impact, but will ease our life in future. This includes a bunch of code cleanups. Most changes were done by Kurt Roeckx and me, but as usual Marc Brockschmidt and Philipp Kern were also involved. This round of changes was started with redoing our priority calculation. Up to now, any package had a fixed place in the list, and our list was built from top to bottom as far as buildd power was available (putting aside manual intervention by setting build-priority by admins). That meant of course that some packages could be stalled if buildd time isn't enough anymore, like currently on mipsen. (The queue order was determined by the following sort options: build-priority, (>= standard?), already built in the past, priority, section, name, and the first difference decided list order.) Now, of course >= standard packages are still built first, but waiting days increase priority so that old extra packages could be built before young optional package (in other words, they shouldn't stall. The new formula is about: required: 50, important: 40, standard: 30, optional: 5 [priority] + libs: 4, devel: 2 [section] + contrib: -20, non-free: -40 [component] + out-of-date: 20 [notes] + max(6, waitingdays) * 2 + manual priorities, and packages are ordered by this number, then by waitingdays, then by name.) While adding code to add bonus for long-waiting packages, we stumbled across the fact that there were non-C dates in the database stored, which in turn means that export of the database stopped to work. For fixing that we replaced the last change field in the database by an postgres now() on insert, and converted that field to an date field (instead of freetext). Which in turn broke mkstats and a few more things, which are fixed as of now. While doing that, we also introduced the format option, which allows to do queries like:

wanna-build --format='%t %u: %p/%v% +b B%B' -A mipsel --list=building

which gives output like:

2010-03-03 15:24:38.642988 buildd_mipsel-mayer: cracklib2/2.8.16-1
2010-03-03 15:30:00.341313 buildd_mipsel-rem: liblouisxml/2.1.0-1+b1

Of course, there are even better possibilities what one could do with that. :) More changes are pending, like the injector for log files was changed so that we record building times in the database. This will allow us to include build time on at least a few buildds, so that large packages cannot so easily stall all buildds completely anymore. So, more to come ...

I'm really delighted, thet you are here! You know, I started quite late with that whole IT business, and Debian was my first distribution. It all worked perfectly and took all my fears of it away!