Say no to ProFTPD January 15th, 2008
It looks like people are still recommending ProFTPD. I wish they wouldn't. This isn't news. It's an opinion I find myself repeating frequently, and now I'll be able to cut'n'paste or provide a URL as appropriate.
Search the National Vulnerability Database for vulnerabilities disclosed against vsftpd and ProFTPD during 2004, 2005 and 2007. You could search all of time, but that would give you a skewed view, because ProFTPD is older than vsftpd, and because you need to allow for software becoming more secure over time.
You'll find 8 vulnerabilities in ProFTPD. One of them is an authentication bypass vulnerability. The rest are stack and buffer overflows that allow denial of service attacks and remote code execution.
You won't find any vulnerabilities for vsftpd.
I used to buy the argument that ProFTPD is more feature rich. But recently, I set up vsftpd for a customer, providing chrooted sessions for virtual users. It was a lot less hassle than it is with ProFTPD.
Interestingly, vsftpd is (at the time of writing) the FTP server software used by kernel.org, the Linux kernel distribution site. From the perspective of a black hat, there aren't many non-commercial sites that would be more useful to break into, so their threat exposure is probably high.
Say no to FTP. If you can't, say no to ProFTPD.
Pinning down Etch backports September 30th, 2007
For a while, I've wanted kde-3.5.7 on my Debian 4.0 (Etch) laptop. It's available in the etch-backports archive from backports.org. But the etch-backports archive contains a lot of other backported packages, and I want to stick to Etch with the exception of KDE.
You may ask why I don't just accept all packages from the etch-backports archive. There are two reasons: stability and security.
With respect to stability, I reckon that the packages in the etch archive have probably been exposed to the largest number of users. Assuming that a wider user base leads to more bug reports and fixes, these packages would be the most stable. That assumption doesn't always hold, but it's a good generalisation, as generalisation's go.
An enormous amount of effort goes into producing a stable Debian release, and I want to maximise my leverage of that effort. As I become more of a manager, my interest in a bleeding edge laptop wanes.
As for security, the Debian Security Team FAQ suggests that the testing archive can receive security updates less frequently than the etch archive. Since the general backports.org policy is to backport only from the testing archive, I figure I'd wait longer for security updates from the etch-backports archive.
So for the most part, I want packages from the etch archive. For KDE, a suite of hundreds of packages, I want what's in the etch-backports archive.
The solution, as presented by the instructions at backports.org, is to use APT preferences to pin specific packages to the etch-backports archive. Unfortunately, the format of the APT preferences file requires that you pin every single package of the KDE suite. With a full KDE installation comprising over 200 packages.
This seemed like it would be a lot of work, especially since I couldn't find the list of packages for the KDE suite in a single list. Rather, I'd have to navigate an extensive dependency tree, ignoring dependencies that aren't part of the KDE suite.
However, I noticed that all the packages from the KDE suite contain the same text in their long descriptions:
This package is part of KDE
How fortunate. Especially since the dctrl-tools package provides a way to search for packages matching against any header in the package control file.
So after following the instructions at backports.org to add the etch-backports archive to my APT sources and update my package index files from their sources, here's what I did to tell APT to accept KDE packages, but nothing else, from etch-backports:
aptitude install dctrl-tools
grep-aptavail -ns Package -F Description \
"This package is part of KDE" | sort | \
for pkg in `cat`; do
echo
echo Package: $pkg
echo Pin: release a=etch-backports
echo Pin-Priority: 999
done >> /etc/apt/preferences
aptitude dist-upgrade
The grep-aptavail options instruct it to print out the value of the Package header (but not the name of the header) for all packages available to APT with a Description header that contains "This package is part of KDE". In short, it prints a list of all packages in the KDE suite. The output is then sorted, transformed into a set of APT preference records, and appended to the APT preferences.
Now I can rest assured that any packages I install from the KDE suite will be installed from the etch-backports archive, but other packages available in etch-backports will not be installed unless I deliberately pin them too.
The same approach works for OpenOffice.org. In fact, it's likely to work for any suite of software where the package maintainers have done something sensible with the package descriptions. All packages in the OpenOffice.org suite contain this text in their descriptions:
OpenOffice.org is a full-featured office productivity suite
Now you can have the toys that the cool kids have, without being cool.
Surviving the expat upgrade on Gentoo February 28th, 2007
Moving to ~x86 on Gentoo Linux requires an upgrade to dev-libs/expat-2.0.0 from dev-libs/expat-1.95.8.
Unfortunately, the expat maintainers broke its ABI between 1.95.8 and 2.0.0 without bumping the library version number. This means the Gentoo ebuild maintainer can't easily slot the versions for happy coexistence.
Whether you've already upgraded dev-libs/expat and are now stuck, or you're still using a version earlier than 2.0.0 and are about to upgrade, this will get you over the hump:
cd /usr/lib emerge -1 '<expat-2' cp libexpat.so.1.5.0 libexpat-1.95.x.so.1.5.0 emerge -1 '>=expat-2' ln -fs libexpat-1.95.x.so.1.5.0 libexpat.so.0
Then, one day when your initial ~x86 upgrade is complete, you can go back and remove libexpat-1.95.x.so.1.5.0 and libexpat.so.0 from /usr/lib once you've used revdep-rebuild --library=libexpat.so.0 -pv to verify that the pre-release library has no remaining dependencies.