Stuart Herbert

… but sometimes there’s just nothing else to be done.

I’ve justed package masked dev-php/asp2php. This package contains two confirmed buffer overflows, which can be used to maliciously install files using the permissions of whoever runs the script. This fault was first discovered a couple of weeks ago, and is one of the now infamous 44 problems discovered and reported by D. J. Bernstein.

It’s a buffer overflow. They happen to even the best of packages. Normally the fault gets fixed, a new version comes out, and life goes on. But not in this case.

Unfortunately, the author of asp2php either doesn’t understand that it is his code which contains the fault, or he simply doesn’t care. Honestly, I don’t know which. But either way, his denial leaves Gentoo with a problem. It leaves Gentoo with three choices:

1. Continue distributing the package, but warn users that it contains known security holes. Well, I’m not going to say that this should never happen, but it’s not something any responsible distribution can do regularly. There’s a trust thing between users and their Linux distributions, and part of that is being able to trust that the packages a user installs don’t contain known security holes.
2. Fix the package ourselves, and (hopefully) get the patch accepted upstream. This does happen sometimes, but does Gentoo really want to be stuck having to patch a package because the original author doesn’t want to fix his own code? What’s going to happen the next time? Or the time after that?
3. Remove the package, and publish a security advisory advising everyone to uninstall the package. It’s the saloon of last resort, but it’s the responsible thing to do with abandonware. An upstream package with known (and unfixed) security holes is a form of abandonware. Exploits allow machines connected to the Internet to be turned into zombies; machines used as relays to send spam (or worse) to other machines, and ultimately to me and you. Security matters, and anyone who has a cavalier attitude towards it should not be writing or selling software.

… and if you run any older version of Wordpress, you’re strongly advised to upgrade pronto. Stable on x86 and ppc.

… along with a patch to make it really delete files from the underlying versions directory. Without the patch, the versions directory soon fills up with temporary files created by vim and other editors.

… there are a number of gotchas in the existing 2004.3 release + documentation that you will need to work around. If you try and follow the existing documentation to the letter, you’ll be left with an installation that just won’t boot I don’t have access to any other type of PPC machine, so I can’t comment on whether these problems exist when installing Gentoo/PPC onto other hardware. Maybe they do; there’s only one Gentoo bug in here that appears to be Pegasos-specific.

Here’s a list of problems & workarounds that I’ve either seen myself, or kindly had forwarded to me from Genesi . I’ll get some bugs filed for these problems later in the week when I’ve got a bit more time. There’s also a few more potential problems that I need to verify before I can file bugs.

• PPC Handbook says that the Pegasos does not need a boot partition. This is only true if your root filesystem (containing /boot) is an ext2 filesystem. The handbook currently doesn’t mention the need for /boot to be on an ext2 partition. As with x86, make /dev/hda1 a small boot partition (say 20Mb to allow you to keep some old kernels around) and format it as ext2. This problem will prevent Gentoo from booting on your Pegasos machine.
• The PPC handbook does not mention that your compiled kernel must be less than 4Mb in size. The Pegasos firmware defaults to being able to load a maximum boot image of 4MB. This can be increased by setting the “load-base” variable in the firmware. If you think you’ve run into this problem, change the value of the “load-base” variable in the Pegasos’ firmware to 020000000, and then try to boot your kernel.
• The stage 3 tarball contains a pam authentication bug. When you reboot into Gentoo Linux, you won’t be able to log in from stage3 (stage2 is fine). This is a problem reported to me; I always build from stage1 because Gentoo’s choice of default CFLAGS on all arches don’t suit me. If you run into this problem, start from the stage2 tarball for now.
• The PPC handbook does not include the firmware command to boot the installed kernel image. The manual simply says “You don’t need a bootloader; just reboot the box.” It’s true that you don’t need a bootloader – the Pegasos firmware will handle that – but the default firmware configuration tells your Pegasos to boot into a bootmenu installed on /dev/hda1. If you’ve followed the PPC handbook closely enough, that bootmenu is gone, and your Pegasos won’t boot without your intervention. If you’ve created a boot partition at the start of your disk, the command you want is “boot /pci/ide/disk0,0:0 kernel-2.6.9″.
• Neither devfsd nor udev/coldplug are installed in the stage tarballs, and the PPC handbook currently doesn’t mention that you need one or the other. I haven’t used udev/coldplug myself yet, but it’s the future so I guess you should install those instead. Make sure you install devfsd or udev/coldplug after you’ve finished building stage3.

… and as promised I’ve done some primative benchmarking against my other dev boxes. These benchmarks are absolutely not scientific, and your own milage will vary. These figures merely represent my own experience working on the packages that I help the Gentoo community project with.

Here’s the result of emerging apache-2.0.52-r2. All tarballs had already been downloaded. Options such as ccache and binpkg were switched off, to try and make this a fair shootout. Slowest first:

• VIA Nehemiah EPIA M10000
  • real 14m28.472s
  • user 10m6.210s
  • sys 3m13.490s
• PPC:
  • real 7m58.429s
  • user 5m21.681s
  • sys 2m25.963s
• Athlon 64 3500+ (32-bit Linux, mostly compiled for Athlon-XP):
  • real 7m16.913s
  • user 4m49.541s
  • sys 1m0.441s
• Dual-Xeon 2.8GHz:
  • real 4m37.491s
  • user 2m56.962s
  • sys 2m34.929s

I think the Genesi Pegasos II machine has aquitted itself very well. It kicks the crap out of the VIA EPIA platform; so much so that I can’t help but wonder whether a mini-ITX form factor Pegaos II could make a real dent in the EPIA’s market. The Pegasos is much faster, even quieter (the EPIA M10000 isn’t totally passively cooled, but the Pegasos is), and (because it’s not x86) I’d expect it to be a little harder for the script kiddies to break into if you want to use it as a firewall.

The real disappointment (for me) is the dual-Xeon … it’s a screamer of a box, but ebuilds for smaller packages just don’t get the most out of the machine. GNU autoconf (in particular) is just too much of a bottleneck. If you’re looking to spec an on-site build-box to make binary packages for your in-house Gentoo machines, you might want to see if anyone has any benchmarks of using a P4-EE for the job.