Month: June 2012

During the workspace sprint I had several discussions with the Usability expert Björn Balazs (of open usability fame) about how to bridge the gaps between usability teams and developers, how to improve the communication and trust between the two and how to increase involvement.

One of the actions we undertook was a trial run of offering the chance of usability input during the code review process. To do this we have added a usability group on reviewboard which can be assigned to add a UI check to any code checking.

Developers, from now on if you create a patch that has a significant UI change, such as the introduction of a new dialog simply add the group "usability" to the list of groups that should review your code in addition to the normal maintainer group. The usability team will be notified that you want them to review and make any comments we deem needed or hopefully just told the team approve. If you do this, you should make sure your patch on reviewboard is accompanied by screenshot(s). Ideally in the form of "before", "after" where applicable.

This release cycle we're trying to improve the KDE quality process and add in some structured testing. This is a new program so we're trialing a lot of new ideas.

Application testing checklists

I've taken responsibility for testing all the newly rewritten QML plasmoids with a thorough checklist to make sure everything new is up to scratch ready for a great Plasma future.

This also exists for some other KDE apps (see wiki pages for details), and hopefully more in future.

Bug hunting days

On the weekend of the 9th and 10th of June we will be running some bug hunting days. This will involve IRC training in good bugzilla usage, we will then spend the weekend in an intense testing and bug triaging session, with developers spending some of this time fixing these bugs.

Change testing

Also we're trying to identify all the new areas of medium-large changes and identify these as "areas that should get some more thorough testing". Developers, we need you to update this list with any new features that have been added or areas that have had big rewrites. Users, when you're testing go through this list, and give a bit of extra focus to these sections.

Developers and users, get involved!

What is it?

Google offer a two step authentication system for their websites where, in order to log in, a user must enter both their password and a special number displayed on the user's phone using a special app that displays a changing unlock code. This code is only valid for a 2 minute window, and so a hacker needs access to the device as well as your password in order to log in.

An implementation behind this is also available in the form of a PAM module so you can install the same security on your PC. Despite being written by Google engineers, everything is run locally and it does not use your Google account.

As well as installing the PAM module you will want to download "Google-Authenticator" from the Android marketplace or iPhone store. Both of these are open source.

Installation & Usage

Install through your package manager

sudo apt-get install libpam-google-authenticator

or download the source

Once installed, run

google-authenticator

. You will be prompted with a series of questions, and then a secret key will be provided. Alternately scan the barcode into the phone to set everything up automatically.

Konsole output	How it appears on an Android phone

Integration in LightDM-KDE

I added support for this method in an experimental branch of lightdm-kde available at: git://anongit.kde.org/scratch/davidedmundson/lightdm-kde.git in the branch google-auth.

In order to use the two-step authentication we need to add the following line

auth required pam_google_authenticator.so

to one of the files in /etc/pam.d. Each file represents an authentication usage, and adding this line tells it we require google_authenticator to log in.

Add this line to /etc/pam.d/lightdm to force LightDM to prompt for the two-step verification code. It can be added to other files to prompt on console login or sudo for example, but note that it will not work in KDM.

The Future

PAM support in graphical prompts still needs a lot of work, this mostly stems from the fact that PAM was not really designed with graphical interfaces in mind.

Moving forward we need graphical interfaces to configure PAM, and GUI support for a range of modules, not just in LightDM-KDE but also in PolKit prompts, lock screens etc. I intend to kickstart this on the LightDM side, to support more PAM methods in a more elegant way and hopefully improve the existing kgreet library.