Installing CyanogenMod 7.1 Alpha 3 on my HP TouchPad
24 Feb

Installing CyanogenMod 7.1 Alpha 3 on my HP TouchPad

I have just finished installing CyanogenMod 7.1 Alpha 3 on my HP TouchPad. Its gorgeous. I cant say I ever become a fan of WebOS, unlike some I’ve talked to it never grew on me and the rare times when I did want to make use of it the App Market was far too over priced and in my experience limited, but now with Android the device ‘sings’

The install was a breeze in the end, all the same here are the steps I went threw. I never needed to do any disaster recovery so I don’t list any. How ever I would highly recommend anyone interested in doing this to read the FAQ at before going any further it contains all the disclaimers and alpha-software warnings you would expect as well as an in-depth list of disaster recovery options.

The Install Instructions for a fresh install

  1. Prepare your PC for the installation by downloading the Palm SDK from the HP website. The site has full easy to follow instructions for Linux, Windows and OS X users so replicating them her seems redundant. Once you have installed the the SDK you can continue with the steps listed bellow.
  2. You now need to download the required software. At the end of it you will end up with the four files:
    • – RootzWiki Forumi
    • – RootzWiki Forumi
    • – RootzWiki Forumi
    • – Moboot Projecti
  3. If you wish to have access to the extra Google apps, like Gmail, YouTube or the Android Market you will have to download the latest gApps installer from the CyanogenMod wiki site
  4. Unzip the file. On Linux systems you can leave it where you downloaded it too, but in Windows at least it will make like a little
    easier if you move the unzipped file to the same directory you installed the Palm Novacom SDK to. On my VirtualBox machine it is C:\Program Files (x86)\Palm, Inc but I’m running a 64bit system, in 32bit the directory will probably be C:\Program Files\Palm, Inc
  5. Now connect your TouchPad using its USB cable to your PC. The TouchPad will notifiy you that its detected a new USB connection. Tap the symbol to mount the tables SD card on your computer.
  6. Open your file manager and on the root level of the SD card create a new folder called cminstall. Into this new folder copy the zip files you
    downloaded before, do not unzip them and don’t copy file, just leave this file on the PC for now. Once your done the contents
    of your new “cminstall” folder should be:

    • – *You only need this if you’re planning to install the extra Google Apps
      7.You now need to reboot the TouchPad. Make sure you eject the TouchPads SD card correctly from your PC, some systems delay writes to external USB devices to speed things up.
      Once the TouchPad has been removed follow these steps to reboot it, while the USB cable is still connected:
    • Press the Home Button
    • Bring up the Applications List
    • Select the Settings Tab
    • Open Device Info
    • Press the red Reset Options button at the bottom of the screen
    • Press the grey Restart button at the top of the screen
  7. As the TouchPad reboots the screen will turn off, as soon as this happens press and hold the Volume-Up button. Keep holding it until a USB icon fills the display. After a few second your computer will recognize the TouchPad.
    • Under Linux, open a terminal and change directory to the where you unzipped the file
    • Under Windows, open a command prompt and change directory to where you installed the Palm SDK:
    • Open the start Menu
    • Type cmd (no quotes) hit enter
    • A black and white terminal window should have opened
    • To change directory, type cd c:\PATH for me the path is C:\Program Files (x86)\Palm, Inc so I typed: cd C:\Program Files (x86)\Palm, Inc


  8. On both systems enter this command novacom boot mem:// < ACMEInstaller
  9. Make a cup of tea. That’s really all there is to the install. It will take a few minutes but once its done the TouchPad will reboot into Android
Non-Root Ubuntu Shutdown
24 Feb

Non-Root Ubuntu Shutdown

It may at first seem rather daft that you must become root before you can shutdown you PC, but it does make sense. Linux is designed as a multi-user system, just think of any web site you’ve ever visited. Many different people can be accessing the same site at the same time and that’s to say nothing for the other people hosting their site on the same machine. Could you imagine the chaos that would result if any one of those users were able to turn that machine off at will? You may still be thinking “ye, but they could pull the power” but, they couldn’t, the users I am referring to have no physical access to the machines in question so securing the shutdown commands in this way is still highly effective.

In my research I have come across a couple of different methods to achieving the goal of non-root shutdown. The /etc/shutdown.allow file is a common option, however it fails the ‘usability’ test for me as it requires a number of other steps and relies on keyboard shortcuts to be correctly configured and not intercepted by other process. Because of that I have decided to go with the sudo method as my recommended choice.

The SUDO Method

In-order for user of the ‘shutdown’ group to turn off the machine we must create the group ‘shutdown’. So run this command, prefixing it with sudo to make sure it is run as root

Next we need to start adding people to our new shutdown group. This command will do the job, just replace username with your username.


Anyone you add to this group will be able to shutdown your computer, even when they’re not sitting at it so be selective in your choices. The next thing we need to do is give the shutdown group permission to invoke the command for shutting down or rebooting. In Linux these command are /sbin/shutdown, /sbin/reboot or /sbin/halt so now run the visudo command and add the following lines.

That’s you done. Now anyone in the shutdown group can now run sudo shutdown as if they were root and shutdown the computer.

The Next Step?

At this point you may have notice that users still have to prefix the shutdown command with sudo. I personally like this as it reduced the risk of typo etc.. but I know for some (or most) its still a pain, so we can remove it.

What we need to do is create a script in /usr/local/bin/shutdown which prepends the sudo command for us.

Now just make the script executable and, for a little extra protection, change its ownership to out new shutdown group

OpenPGP: Key Signing Policy
19 Feb

OpenPGP: Key Signing Policy

Since April 2012 I have held the position of Chairman of The Software Society Ltd. On the 23th of March this year, 2013, it was decided that the board of directors and office bares (Chairman, Company Secretary and Chief Financial Officer) should all create an use OpenPGP keys for all official business.

It was also decided that each office barers key should last as long as they are in office, the new incombant creating a new key apon their election.To this end, during my time in the post my key will be 0x6415679569aa4946 and will be subject to the same signing policy as I has been in use on my personal key. This is detailed bellow.


This policy is valid for all signatures made by the following GnuPG keys:

The most recent version of these keys are available from the key server at or for download from My GPG Page

This policy was first written on 2011-06-22 but the polices listed here have been followed since the creation of the key four days earlier on the 18th. Content and structure of this document are strongly based on the OpenPGP Key Signing Policy of Marc Mutz (Link no longer available) and Jörgen Cederlöf (Link no longer available) but have been slightly modified from the original sources.


I live in Dundee (Scotland) and am available to sign keys any time. If you want to arrange for a key-signing, your best chance of meeting me is in or near Dundee. Occasionally I’m in St.Andrews, Cupar and Perth. I can be reached thru the/feedback form on this site, Just be sure to include the phrase ‘key-signing’ in the subject line. I am also listed at, a webpage about key signing coordination. Meetings at computer related fairs are possible as well.

Usually I keep track of upcoming events where it would be possible. So if you would like to meet in order to sign keys check my events diary to find out where I will be.

Prerequisites for signing

The signee (the key owner who wishes to obtain a signature to his/her key from me, the signer) must make his/her OpenPGP key available on a publicly accessible keyserver (see above for example keyservers).

The signee must prove his/her identity to me by way of a valid identity card or a valid driving licence. These documents must feature a photographic picture of the signee. No other kind of documents will be accepted. This also implies that the signee’s key must feature his/her real name in order to be checked up on his/her identity card. A key which only contains a pseudonym will not be signed.

For people from outside the European Union I will check both of these two tokens (since I cannot assess their risk of fraud). Exceptions may be made if there is a good reason for me to do so.

The signee should have prepared a strip of paper with a printout of the output gpg --fingerprint 0x12345678 (or an equivalent command if the signee does not use GnuPG) where 0x12345678 is the key ID of the key which is to be signed.

A handwritten piece of paper featuring the fingerprint and all UIDs the signee wants me to sign will also be accepted.

The above must take place under reasonable circumstances (i.e. ourselves not being in a hurry, exchanging key data at a calm place and so on).

The act of signing

After having received sufficient proof of identity I will sign the signee’s piece of paper myself to avoid fraud, and eventually sign the signee’s key.

The signed keyblock will then be mailed to the signee, or uploaded to a keyserver if expressly wished.

Key signing is performed on the understanding that the act of signing is mutual. If the signee fails to sign my key in return I reserve the right to revoke my signature from their key.

Signing requests of transitions to new keys

I have been asked what my position is towards requests from people (whose keys I had already signed) to also sign their new keys.

In principle, I agree to the procedure when I am reasonably sure the request is not bogus/a scam, and the following conditions are met:

Any signing request of transition to a new key

  • must at least be signed by the still valid original key (which I also signed),
  • the new key must also be signed by the still valid original key (which I also signed),
  • the owner of the new key must cross-sign my keys in return with the new key first,
  • the new key will receive the same level of signature as the still valid original key (which I also signed).

However, such a signing request may be declined without giving reasons. If unsure, enquire first.

Levels of signatures

Level 0

A level of 0 is given to keys of Certification Authorities since in most cases the key owner is a whole organization and not a single person. Usually the fingerprints of those keys have to be verified by getting them from the corresponding website of the CA and cannot be checked by exchange with a member of the CA who is in charge. These signatures are the weakest in my web of trust.

Level 1

If I have had contact with someone through signed or encrypted e-mail over a time long enough to rule out at least temporary man-in-the-middle attacks, and I have verified the key with a key downloaded from his/her personal web page, or signed emails/fingerprints on public mailing lists, but I have not met the person or verified the key in any other way, I may sign the key with cert check level one.

Level 2

A level of 2 is given to sign-only keys. It is not clear to determine if the owner of the mail account is the same as the key owner because encryption cannot be used, hence the signatures only receive a lower level of 2.

Level 3

A level of 3 is given to sign-and-encrypt keys: I have met the signee in person, I have verified his identity card (passport, or driving licence) and his key’s fingerprint. I was also able to send my signatures encrypted with the corresponding key of the signee. These signatures are the strongest in my web of trust.

Photographic UIDs are also going to be signed with a level of 3 if I can still remember the signee’s face when I will be back at home.

I will also sign keys at level 3 when I know the signee personally, I do not require ID card or the above formal procedure. A meeting where we exchange fingerprings is enough. Naturally, it would be extremely hard to trick me into signing a false key this way.

Here are some links which you may find useful or interesting: Key signing policies of other people:

Change Log

  • Version, 2014-12-14 – Content migrated to new markdown site
  • Version, 2013-09-21 – Applied this policy to my smartcard key
  • Version, 2013-03-25 – Applied this policy to my second key
  • Version, 2013-03-22 – Removed dead URL from links
  • Version, 2012-01-19 – Content Recovered from Google Cache
  • Version, 2011-11-30 – Initial Release.