Hardened Desktop

My work desktop is on one of these university networks where you have an internet connection in the most direct sense. No NAT, no significant firewall, fast pipe. Which naturally gives you an interesting attack surface; while I only allow ssh login via public key cryptography, it's still amusing to watch all the automated "invalid username" login attempts from all over the world. Anyway, some time ago I decided that this deserves some more attention, and switched to a hardened profile...
So, about profiles. You have probably seen this string default/linux/amd64/10.0/desktop before. A profile actually is something pretty simple- a set of predefined defaults for e.g. use flags, system set, package and use masks, ... The main purpose of the desktop profile, which many people use, is to provide sensible defaults for a typical desktop workstation, i.e. enabling useflags like "consolekit jpeg png". Profiles are inheritance-based, meaning this desktop profile inherits defaults from linux and from amd64. You can select your profile with eselect profile, but in the end whatever that does is only redirect the symlink /etc/make.profile to the appropriate target in /usr/portage/profile.
eselect profile also provides a list of profiles to choose from. Here on my laptop this is

huettel@porto ~ $ eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/10.0
  [2]   default/linux/amd64/10.0/selinux
  [3]   default/linux/amd64/10.0/desktop *
  [4]   default/linux/amd64/10.0/desktop/gnome
  [5]   default/linux/amd64/10.0/desktop/kde
  [6]   default/linux/amd64/10.0/developer
  [7]   default/linux/amd64/10.0/no-multilib
  [8]   default/linux/amd64/10.0/server
  [9]   hardened/linux/amd64
  [10]  hardened/linux/amd64/selinux
  [11]  hardened/linux/amd64/no-multilib
  [12]  hardened/linux/amd64/no-multilib/selinux

The list comes from /usr/portage/profiles/profiles.desc. However, if you are brave (or insane), nothing keeps you from manually pointing your /etc/make.profile symlink to a different directory. As it turns out, there is a worthwile target hidden away, which provides a "hardened desktop" profile:

huettel@grenadine ~ $ ls -l /etc/make.profile
lrwxrwxrwx 1 root root 52 24. Jan 18:45 /etc/make.profile -> ../usr/portage/profiles/hardened/linux/amd64/desktop

So, if you want to void all your warranties, set your symlink like this and your profile will inherit from both hardened and desktop profile. Then follow the rest of the guide for switching to hardened.

What will you lose? Mainly, nvidia-drivers, ati-drivers, and skype. All three do at the moment not play nicely with hardened protection features. At least in the case of skype that is pure lazyness by the company; the programmers of skype could easily fix it if they wanted. In addition, the security benefits will lead to a performance hit; how much I cannot really judge yet.

What will you gain? For example, Stack Smashing Protector (SSP), Position Independent Executables (PIEs), Default full binding at load-time (BIND_NOW), ... There's a lot of documentation on hardened floating around, and I'm only just learning...

I'm running a full KDE desktop with radeon driver and accelerated graphics, so far I have not noticed any unpleasant side effects yet. I'll stay with it. :)

What about my precious Xpdf ?!?!?

I keep getting e-mails asking me why app-text/xpdf is masked for removal from the portage tree. It's getting too much to reply individually, so let me sum up the situation here in a blog post.

# Andreas K. Hüttel <dilfridge@gentoo.org> (27 Jan 2012)
# Has developed into an unmaintainable mess, and everyone who
# knows about it is either retired or missing in action.
# Several minor bugs and one ugly security issues (#386271).
# Masked for removal because of lack of maintainer.
# Please try app-text/epdfview as light-weight replacement.
app-text/xpdf

Xpdf is a package with a long history, and in a way a strange remnant of bygone times. Since PDF rendering is a function that many different programs could use, some years ago the Poppler library was forked from the Xpdf codebase. By now, Poppler is a much more active project, and used by dozens of packages in the Gentoo portage tree, all the way from LibreOffice and PDFTeX to Calligra, GIMP, and e.g. Okular or Evince. Being the more active project is important in this case, because PDF files are frequently shared and distributed and PDF rendering is thus a security-relevant task.
The original Xpdf remained independent of Poppler, not using the library - with the effect that every now and then security bugs kept popping up. Some time ago, some Gentoo developers started modifying and patching Xpdf to use the Poppler library. What resulted was the complicated construct that right now noone here is willing to maintain anymore. (Otherwise some Gentoo developer would have contacted me in the meantime.) Implementing a version bump to a more recent Xpdf version is a non-trivial task because all the Gentoo-specific patches have to be reviewed and if necessary rewritten.
Thus, app-text/xpdf needs to go the way of the dinosaur. Two alternatives exist, but both do not seem realistic at the moment:
1) We could go back to the original, unpatched Xpdf from upstream. I'm not going to do it, and I doubt anyone else of the Gentoo devs will.
2) Rogério Brito has started maintaining a fork of Xpdf at Github, which uses the Poppler library. However, there is no released version yet, and as he told me myself, he's rather busy in real life right now...
In the meantime, please try one of the following packages:

• app-text/zathura (based on poppler & gtk+)
• app-text/apvlv (based on poppler & gtk+)
• app-text/epdfview (based on poppler & gtk+, ~unmaintained)
• app-text/mupdf
• app-text/gv (based on ghostscript)
• app-text/evince (based on poppler, Gnome application)
• kde-base/okular (based on poppler, KDE application)
• app-text/acroread (yes I know...)

Ironically, the first mail reply to the last-riting of xpdf was from one of our security team members, promising me a beer the next time we meet in person. Only afterwards the complaints started.

Gentoo zero-day packaging of new KDE releases explained

Usually, whenever a new KDE release is published, Gentoo users can update already the same day, as suddenly a complete and polished set of ebuilds appears in the portage tree. (Stay tuned on upcoming wednesday for KDE 4.8.0, it's shaping up very nicely!) How is this possible? Well... let me explain.

If you're a stable version user, you may have never heard of so-called live ebuilds. This is a special variant, usually denoted by a version number ending in 9999, that does not rely on a source tarball. Instead, it contains a URL of a revsion control system (say on anongit.kde.org). When you emerge such a version of a package, the sources of the specified branch are checked out or updated to the newest upstream state, and that is used for building the installation package. Obviously this is not for everyone; depending how well upstream structures commits, things may not build for a while, contain fresh bugs, ... Also, reporting bugs from live versions on Gentoo bugzilla is discouraged as most of the times we can't do anything about it (do it only if you are sure it's a problem with the ebuilds, not with the source). If you're running live, you should be willing to hack yourself and work with upstream.

However, many of the Gentoo KDE team members run these live ebuilds, partly the current bugfix branch (i.e. KDE/4.8), partly even git master. They continuously keep the live ebuilds in the Gentoo KDE overlay updated to the newest state of the source. When a release is made, the corresponding live ebuilds of this branch are copied to the version ebuilds. For example, the KDE/4.8 branch live ebuilds have the version number 4.8.49.9999 (i.e.
kde-base/kdelibs-4.8.49.9999), so when the pre-release tarballs for KDE 4.8.0 were released to the packagers a few days ago, we only had to copy all 4.8.49.9999 ebuilds to 4.8.0 and immediately had a working set for testing. Most problems at that point are only caused by changes in tarball packaging. As distribution packagers get the pre-release tarballs (that still may change due to last-minute bugfixes) a week before the official release date, these can easily be fixed in time.

This also means that KDE maintenance in Gentoo is really a team effort. Whoever moves a released version to the main portage tree and/or commits bugfixes there builds on all the work that the team has done in the overlay in the meantime. Cheers!

Calling for brave testers: net-print/cups-1.5.0-r2

Maybe some of you have noticed that CUPS 1.5.0 is still hard-masked. Well, the reason for that is simple- at home, I'm nearly not printing at all, and at work, I have to rely on printing too much to tinker with it on the side a bit. So... if you would like to help, please unmask net-print/cups-1.5.0-r2 and give it a try. You will for sure find some problems, as the only thing I tested looong time ago was building it, never actually running it. Report them on bugs.gentoo.org, and we'll have a look... with a bit of luck, the package mask can then go away at some point. Any feedback (also positive) is appreciated. Cheers!

My personal KDEPIM upgrade status

Some time ago when we were filing the first stable request for KDE 4.7 I decided I'd have to give KDEPIM-4.7 also a try. I used to be a pine (and later alpine) user for ages, some time ago I switched to kmail1 (maybe at version 4.2 or so) and have been using it ever since... About the setup, incoming mail is stored and filtered server-side (Novell Groupwise), and accessed as disconnected IMAP.

1) Office desktop.
This one's usually running the latest and greatest KDE RC or beta, with a static IP and something like a 100MBps-FD link to the mail server. No local folders, so this was the natural candidate to test first. I did not even try the data migration, but wiped my entire local configuration of the KDEPIM programs as thoroughly as possible before updating. On the whole this went rather well. From 4.7.3 to 4.7.95 I've seen my share of kmail2 / kontact / akonadi crashes, but none of them really led to bigger problems. Impressively, I could also see each of these crash bugs I hit get fixed on KDE bugzilla in the meantime! Since upgrading to 4.7.97 I haven't had a crash anymore.
The only thing that is really bugging me a the moment is that I absolutely can't drag an e-mail message into another folder (I always have to right-click on the entry in the message list, select "Move to folder", ...). However, that is likely a problem in one of the underlying libraries. :| I would really like to help debugging this problem; if you can give me any clue where to look, please message...

2) Laptop.
Going home for christmas meant spending some time on a train. The days before I had upgraded this box to QT-4.8.0 and KDE+KDEPIM 4.7.95. Again, clean start with a new configuration. On the train I spent some time ironing out bugs there. The GPRS connection was happily going down and up again with every tunnel or less-populated countryside. That's when the akonadi backend started really acting up. When I arrived at my family's place, my e-mail had become fully non-functional (no fetching e-mails, no sending e-mails, the backend making kmail hang, regular crashes, and all fumbling with akonadiconsole did not help). After a while of trying, I gave up, wiped my entire KDEPIM configuration and data and downgraded to 4.4 again. I was impressed how responsive my e-mail program suddenly became.
Talking to other people, it seems that some have problems with bad internet connections, some don't. Maybe I should have used networkmanager, at least Alexxy reports that it's working fine with it.

3) Home desktop.
Well... Here I store my e-mail archive since 1996- that's maildir folders with roughly 50000 messages. Maybe I'll consider upgrading KDEPIM sometime around KDE 4.9.

I'm sorry if this blog entry is demotivating for the program developers. Some time ago I followed part of an animated discussion on irc between a kdepim user and a kdepim developer. Quoting a small part,

<user> first: fix bugs. second:dont change data formats. third: change gui only if absolutly nessary.
<developer> no
<developer> first: have fun; second: make it work for others

While this is of course oversimplifying, both points have clear validity, the first because people have come to rely on the software, the second because it's volunteer work by people enthusiastic about their creation. In the end we'll have to find a good compromise.

kdepimlibs-4.7.3 imap4 regression fix

Attention Gentoo users: If you're running kmail-4.4.11.1 and kde-4.7.3, and if you have been hit by bug 382411 (problems with local filters, cannot upload unread message on imap; see also here and here), please keyword kde-base/kdepimlibs-4.7.3-r1 and give it a try. (You may want to log out and log back in.) This upgrade seems to fix the problem... If I get some positive feedback, I'll fast-track it for stabilization. Cheers!

Unit tests - a useful thing causing occasional pain

For whoever has never heard that expression, unit tests are a way to test the functionality of a program or library in an automated way, by for example checking the evaluation result of test data. This is a great thing and can help massively in identifying coding mistakes. CMake provides a mechanism, and in many KDE packages test routines are included.
So far, so good, this is the theory, now let's look at reality. In Gentoo, the main KDE distribution is split into 295 (!) packages. Many dont have any tests (oxygen-icons comes to my mind as a nice example). Of those that have, 37 now have all the test routines hard disabled, and I guess a few are missing that I still have to add to the list. Why? Well, first of all, you have to know that compilation usually runs in Gentoo as an unprivileged user detached from any graphical desktop session, and this user also runs the test routines. In addition, tests should also run fine "offline", i.e. without internet connection. One of our developers is running a great thing called a "tinderbox", where build and unit tests in various configurations are automated- in an isolated environment, and possibly even without network access. So, what can go wrong?

• The tests need X11. Well, actually we can get around this, with a nice hack called virtualx. A background framebuffer X server is started for the test phase only, and the tests are redirected to that display. Works even sometimes. :o)
• The tests need a dbus session bus. I think we could get around this too, but nobody bothered to do it so far and I'm not a dbus expert. 
• The tests need an entire KDE desktop to interact with. Yes, that happens, and unfortunately, we have to disable them in this case, see above. 
• The tests try to download a data set from, say, IMDB, CDDB, or similar. Bad, bad, bad, see above.
• Next, the tests pop up dialog boxes asking for user interaction. A window asking for a GnuPG passphrase is my personal favourite... 
• And last, what I particularly like is a unit test that fails... and after digging into the test log, I see a fat comment "This does not work yet and needs to be fixed!"

I guess at least part of the above points is a matter of policy. Test routines requiring user interaction can provide valid information, but of course they are not particularly useful for automated testing... Anyway...

PS. This blog post took slightly longer to write since a libreoffice-3.5 build in the background went berserk... load 65, >180 concurrent compilers... :D