Some assembly required

Some assembly required It's anniversary time again: the NetBSD project celebrated its tenth anniversary on 21 March, and the FreeBSD project will celebrate its tenth anniversary on 19 June. Things have changed a lot in that time, and it's time (isn't it always?) to think about how the projects should change as a result.

The Government perspective

As reported in December, I was part of a team from the AUUG "Open Source in Government" committee who presented a paper at a seminar arranged by the Australian National Office of the Information Economy. It was quite an experience, including what was one of the first public appearances of Maggie Wilderotter, the Senior Vice President of Business Strategy at Microsoft. I was particularly surprised by the difference of cultures: I had expected that, of course, but the emphasis was not where I thought it would be. You can read my version of it in my diary for the day.

What interests me from the perspective of this column are some of the aspects of "Open Source" that concerned Government people. Not surprisingly, software upgrading was one. I mentioned that in my article in October last year, and I solicited action, but very little has happened.

In this particular case, a member of the audience was concerned that too much of his time was taken up with upgrading software. That's usually a problem that we associate with Microsoft ("Oh, it's crashed. Reinstall your system"). Free software isn't free of this problem, though:

In the past I've had to use Linux for a number of purposes. One of the things that drives me crazy about Linux is the maze of twisty little packages, all different, that you need to install. Just deciding which one is a problem. Once you decide, you may find yourself in dependency hell and discover that you can't install a package which depends on one version of a library without first uninstalling another package which depends on a different version. Once you've got through that, all is usually well.
BSD has to be better, right? Well, some of the time. A large number of the ports or packages we use come from the GNU/Linux space, so we can end up in the same position. Programs like portupgrade help, but they don't give you the warm fuzzy feeling that you just run them and all will be well. In addition, while it's a good, safe idea to compile the packages rather than install precompiled binaries, it can take quite a long time.

An example

One of the things that occupies my time is writing books. At the moment, I've just sent the final draft of The Complete FreeBSD, fourth edition, to the publishers. One of the programs I use extensively is ghostview: I view the pages of the book on a high-resolution screen and seldom print them out. Recently a message went around the FreeBSD ports mailing list:

The following ports have been marked FORBIDDEN for at least 4 months
and are scheduled for removal after May 1 2003.  Please check for any
updates to your ports and/or discuss the vulnerabilities with the
developers.  If I do not hear anything from you before May 1 these
ports will be removed as scheduled.

archivers/pkzip
comms/efax
devel/viewcvs
print/ghostview
www/netscape7
www/wn

FORBIDDEN means that the port should not be built. It's a variable in the Makefile. In the case of ghostview, it looks like this:

# FORBIDDEN=    "Security vulnerability, see bugtraq id 5808"

I set off to find out what the story was with Bugtraq, and after a bit of searching found the report:

It has been reported that an insecure sscanf() function exists in gv. Due to this function, an attacker may be able to put malicious code in the %%PageOrder: portion of a file. When this malicious file is opened with gv, the code would be executed in the security context of the local user.

Although the report was against gv, it described ghostview as well. It looked like a problem that could be fixable. I decided to build ghostview with debugging symbols and see what was happening. Unfortunately, in the meantime the port had been upgraded. So had X11. To build ghostview, I first had to reinstall X and a number of other ports with portupgrade. It took 18 hours on my laptop, with an NFS-mounted ports tree, and it didn't go smoothly: there were problems rebuilding some of the X libraries. Finally I was able to test the port and discover that it did not, in fact, suffer from the vulnerability.

But how many people are prepared to spend 18 hours to install a PostScript viewer? Sure, with a fast machine and local NFS tree it would only be an hour or two, but even that's too long. Microsoft has complained that too few customers install fixes for their many vulnerabilities. I can't blame them. Running a computer should not involve lots of time maintaining the system.

It's fairly certain that the experience to which the government representatives referred was related to Linux, not BSD. I believe BSD is better than Linux in this respect, but it's still not good enough.

The solution

In a BSD project, when somebody whinges about some deficiency, the typical response is "we'll gladly accept code". In the olden days, that was a good way to get annoying people off your back. It's still a good way, but is it automatically a good thing to get annoying people off your back? The BSDs have long since progressed beyond being a hobby for people who work on "real" operating systems. They're commercially viable alternatives for these "real" operating systems (and of course Microsoft). If we want to stay that way, though, we need to realize that there's more to the operating system than each individual's area of special interest. As I said in October last year, the projects need to pay more attention to the problem. The next ten years will depend on it.