John's Blog

It’s no secret that I’m using WordPress MU for this website. It makes it very easy to keep the main site as well as my and Tati’s blogs updated. Recently I’ve been wanting to continue properly securing the blogs and added HTTPS support as well as Yubikey required logins. Once that was in place my next goal was to get OpenID integrated with the sites again. This way the blogs can be used as our OpenID identify. I also wanted to use OpenID to allow others to comment on posts. I ended up using the WordPress OpenID plugin and with a little tweaking works perfectly with WPMU.

All total setting everything up did not go as smoothly as I had hoped but it all got implemented and is working properly. The easiest part of adding HTTPS support was getting Apache configured. I’m not going to go into detail about how to use SSL with Apache mainly because there are plenty of tutorials available for this.

I ran into HTTPS problems with WordPress itself. I first read the WordPress guide for Administration Over SSL but could not get the force SSL options to work. I ended up using the rewrite rules. The rewrite rules worked fine until I tried adding OpenID. Since they rewrite the URL from HTTP to HTTPS under certain circumstances it was causing the OpenID redirects to fail. Removing the rewrite rules would made everything work. After a while I went back to trying to get the force SSL options working. What I discovered is the following options need to be toward the beginning of the wp-config.php file not the end. Putting them at the end causes them to not be loaded.

define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);

The SSL issues didn’t end there. The OpenID plugin’s FAQ says that the following option needs to be set when using the force SSL options.

define('OPENID_SSL', true);

However, don’t set the OPENID_SSL option because it will cause OpenID logins to fail. WordPress MU (at least 3.0) will redirect to SSL for login and then redirect back just fine without OpenID needing to account for the HTTPS connection itself.

That takes care of getting SSL working getting OpenID working with SSL. However, I did have two issues with getting the OpenID plugin working.

First, I was using the Bad Behavior plugin. I say was because it causes OpenID logins to fail. For some reason Bad Behavior detects OpenID logins directed to the OpenID server that the OpenID plugin has created as attacks on the blog. I have not tried to find a way to make the two work together and instead just removed Bad Behavior. This was an easy decision because in the past few months I was using Bad Behavior it only reports stopping a very low number of attacks.

Second, the latest release of the OpenID plugin does not work properly with PHP 5.3. Luckily there is a patch to fix this. Changing the two lines makes is all that’s need to get it working.

The OpenID plugin works with WordPress MU 3.0 and works with and SSL protected logins. You need to patch OpenID if you are using PHP 5.3 and don’t set the OPENID_SSL option. Also, don’t use Bad Behavior and use WordPress’s built in SSL options instead of rewrite rules.

Tags: openid, ssl, wordpress, wpmu.

I recently purchased a Yubikey from Yubico. What got me to buy it was the discount they’re offering to Security Now! listeners. So far I’m liking it quite a bit and have been looking to use it any way I can. One of the uses I found was to have the presence of they Yubikey unlock and lock Gnome Screen Saver.

Toward the end of the forum thread there is a very nice set of udev rules that work perfect for me and are very clean. I put the following into /etc/udev/rules.d/85-yubikey.rules

ACTION=="add", ENV{ID_VENDOR}=="Yubico", RUN+="/usr/local/bin/gnome-screensaver-unlock"
ACTION=="remove", ENV{ID_VENDOR}=="Yubico", RUN+="/usr/local/bin/gnome-screensaver-lock"

I really dislike the scripts that are in the thread for locking and unlocking the computer. Gnome Screen Saver is a DBus enabled application so controlling it is very easy. Below are the unlock and lock scripts I’ve written. They use qdbus to send the dbus commands. This could be replaced with dbus-send but I use Qt and qdbus’s syntax is easier to work with.

gnome-screensaver-unlock

#!/bin/sh
 
user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
 
if [ -n $user ]; then
        GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
        export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
 
        su $user -c "qdbus org.gnome.ScreenSaver / SetActive false"
fi

gnome-screensaver-lock

#!/bin/sh
 
user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
 
if [ -n $user ]; then
	GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
	export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
 
	su $user -c "qdbus org.gnome.ScreenSaver / SetActive true"
fi

One thing that isn’t mentioned in the forum thread that is very important, this unlocking method is highly insecure. The locking portion is fine but unlocking shouldn’t actually be done in this way. The above udev rules only checks that a Yubikey is inserted. It does not which which Yubikey is inserted. Any Yubikey can bypass your password and unlock the computer. The unlocking script does not preform any additional checks against the yubikey. Due to this, I don’t have the unlock code enabled on my computer.

However, it is possible to make unlocking secure. You can use one of the two yubikey pam modules, Yubico’s yubico-pam and Securix Live’s yubipam. Yubico-pam requires internet access because it validates against Yubico’s servers. Yubipam does not need internet access but you will have to reprogram your Yubikey with a new AES key. The new key must be stored in the computer. Each has it’s advantages and disadvantages but using the pam module with Gnome Screen Saver (I haven’t actually tried so it might not work) will provide you with a secure unlock.

Thinking about secure unlocks there is a clever solution that allows for the Yubikey to be used with SSH without the need for the pam module. If I can find a way (I haven’t looked yet) to have an input that can capture the Yubikey’s output then it would be possible to handle the unlock in a secure manner without the need for the pam module…

Tags: gnome, screen saver, security, yubikey.

I’ve released KDocker 4.4 today. It is mostly bug fixes and clean up. However, there is one major change. The feature to dock when the window decorator close button (the x in the upper corner) is clicked has been removed. This feature was introduced in 4.3 and I really like how it. It gives KDocker a feature that no similar application has. However, I was not able to keep it due to a number of issues it introduced.

The dock when closed feature was implemented via XEmbed. Basically I was creating my own window mimicking the window border of the application’s window. I would then remove the border from the application’s window and embed it into my window. Events would be passed from my window into the embedded window. This should work just fine in theory but it didn’t work out so nicely. Embedding caused five issues. The first four are serious and the last is only an annoyance.

The most serious issue was, it broke drag and drop. This looks to be an issue with X itself because I could recreate the problem using Qt and GTK’s embed support as well as writing the embed calls myself using xlib.

Another issue it caused related to support windows. When the main window was embedded it broke the connection between the main window and it’s support windows. So when docking the main window there were issues docking the applications other windows. This is an issue for applications such as XMMS and the Gimp.

Embedding didn’t get along very well with borderless windows. Applications like Chrome and XMMS draw their own window border in place of using the window manager’s decorations. These applications have special handling for moving when clicking and dragging their border. When they are embedded you end up with one of two situations. You can click and drag the window but only in the container window. So instead of moving the window you just move the window’s contents. The other situation is moving via the border doesn’t work at all. In this case resizing doesn’t work either. Oh, and the minimize, maximize, close buttons might not work either. In both cases you can still move the window using alt+left mouse button but this isn’t ideal.

Focus handling with embedded windows didn’t work correctly between different window managers and possibly different versions of Xorg. Some combinations it was fine. Others focus handling only followed the mouse. There were issues with the embedded window never getting focus or only getting focus when using alt+tab to select the window after it was docked.

The only annoying issue that I was okay with having was when undocking a window the window manager (compiz) would cause it to move a little bit. When undocking the position of the container window is recorded, the embedded window is removed from the container and moved to it’s location. Then the container window is destroyed. Compiz didn’t like placing two windows in the exact same place and kept moving the second window down and right by the size of the decoration and frame. This isn’t a very big issue but I really don’t want to have window manager specific work arounds in the code base.

The decision to remove iconify on close wasn’t taken lightly. It was only due to the large number of issues it created. There is not point in using KDocker if it is only going to make docked applications unusable. I have created a branch for iconify on close so I can hopefully get it working properly.

Tags: KDocker, release.

I’ve made a new release of lebookread. This version supports the following formats: palmdoc, ztxt, epub, tcr, rb, mobi, and fb2. The library is usable but still needs a lot of work. Unit testing, examples, more code comments and more formats to name a few things.

.