Allan McRae

What many people do not realize is that my archlinux.org email address is really just an alias for a Hotmail account. That’s right… I do my Linux development with a Hotmail address! Deal with it… I am not changing.

Recently I got annoyed at the Webmail extension for Thunderbird as it breaks every time the Hotmail site makes a change or a new version of Thunderbird is released (so generally not the extension authors fault). The final straw was when attachments were only being partially downloaded, which I only noticed when some photos I was sent had black bars on them. Then I checked my WordPress backups that are automatically emailed to me and, sure enough, I could not open the zip file because it was corrupt.

Fortunately, your Hotmail emails can be retrieved by POP3 and this had become an option for me as my work no longer blocks that port. Unfortunately, that only downloads emails in your Inbox and not your Junk folder. That should be easy to work around… Just turn of Hotmail’s junk filtering. Right? Well, no… Hotmail has two junk email settings – “Standard” and “Exclusive” – and neither of these is equivalent to “Off”. The “Standard” filter manages to catch about half of the spam I receive and a bunch of valid emails from mailing lists I am subscribed to. I could log into Hotmail every so often and flag the valid emails as not junk (annoying), but Hotmail will delete anything in your Junk folder after ten days (really annoying…).

How to work around this crap? I found in Hotmail’s options there is a item to set up “Rules for sorting new messages”. It appears if an email matches one of these rules, the rule is enacted without running the spam filter. So the spam filter can be disabled by adding the following rule: Move messages to Inbox if sender’s address contains “@”.

That means I am now receiving all of my emails. So, if you send me an email and I do not respond, it is now definitely because I am ignoring you.

Caution: Spoilers follow!

If you are looking for a good game and like JRPG’s, then you can not go past Xenoblade Chronicles. Well, you can if you live in North America where it still has not been released yet and will not be released until April… Now you know how it feels to live in Australia!

Now I have that off my chest, lets get back to the game. Xenoblade is a game of epic scope, both in terms of the shear size of the worlds that you can explore and in terms of the number of things there are to do. And there are many, many, many things to do… To get near “completing” the game, you will need to spend well over 100 hours, making the game quite good value for money.

I am not going to do a detailed review of the gameplay as those are already available elsewhere. Instead I will cover the various elements there are to collect in the game. This is probably an unhealthy obsession of mine that started with Pokemon (Gotta Catch ‘Em All…), but is often an aspect of games that I enjoy more than the primary game itself provided it is not too monotonous.

Party Upgrades: Each playable character in the game has multiple upgrades that can be found (excluding basic things like level and equipment). There are upgrades to each of the “Arts” that are used during battles, which are purchased using “AP” that you collect by defeating monsters or from other tasks in the game. Before the Arts can be upgraded to their full potential, you need to learn the Intermediate then Advanced levels through the use of Books. The Books for the Intermediate level can be purchased at various stores throughout the game, but the Advanced level books are only dropped by strong monsters. At least two are dropped at a low frequency by a monster that appears only once in the game, so unless you know that beforehand, the chance of completing this upgrade is negligible. I collected all Books but have not purchased the full upgrades yet as collecting the required amount of AP would become tedious.

Each character also has a set of “Skills” that are like innate abilities that improve your battle prowess. There are learnt by collecting “SP” when defeating monsters and filling up the “skill tree”. Each character starts with three skill trees, or sets of skills of a given type, but two additional skill trees can be earned for each character. Enough “SP” will be earned to fill up most of the characters skill trees just by playing the game, but a couple of characters would require repetitive monster killing to complete.

Quests: There are 480 quests given to you by various NPCs during the game. Some are essential to complete in order to progress through the game, but others are just useful for gaining experience/money/items. What is really annoying are that some quests only appear under certain conditions. I do not mind those that are mutually exclusive (i.e. you can complete one of two quests and it really does not matter which), but those quests that only appear if you do something in a particular way (with no real indication of what that is…) are… well… I can not find a polite word to describe them. Then there are timed quests. These become unavailable (without warning) once you reach certain points in the game. So if you are wanting to complete “all” quests, you need to do each quest as soon as you are assigned it and spend lots of time exploring each region to make sure you have talked to everyone. I believe I completed all possible quests for a single play-through apart from one that was unavailable as I made an “incorrect” choice during the game.

Affinity: There is an “affinity” system that essentially measure how much people like each other. Importantly from a gameplay perspective is how much the people of each region like you and how much the members of a party like each other. How much people of a particular region like you determines the available quests and items available for trading. This is improved by talking to the various NPC who have names and completing quests. The affinity between members of your party is improved by helping each other in battle and through the completion of quests together. It is not a super-important area of gameplay although it does let characters use skills known by other characters and allows you to see “Heart-to-Hearts” (see below).

Region Maps: There are around 20 areas (depending on how you count them) to explore during the game. Each of these regions had a number of “Landmarks” and “Locations” for you to find to unlock the complete map to the region. The Landmarks serve as warp-points, which avoids much mindless wandering from place-to-place. Almost all of these would be found during normal gameplay and the remaining few during completion of quests.

Collectopaedia: Each region has a list of items that can be collected throughout it. Collecting one of each of these fills in the Collectopaedia. Just like the Quests, there are points during the game where access to the areas becomes no longer possible (without warning…) so it is important to collect these as you go. There is also a selection of items needed to complete this that can only be traded for, with one requiring an item to trade that can only be found by defeating the strongest monsters in the game (and is the one item I have yet to collect).

Heart-to-Hearts: These are cut away scenes showing conversations between characters that are supposed to provide extra insight to their inner thoughts… You get to chose various answers that direct the outcome of these conversations, although I never actually read the text so I have no idea how much your choice mattered. What I did notice was that the “acting” during these interactions was horrible.

Unique Monsters: Now this is a fun part of the game! There are 157 “unique” monsters in the game. Some are truly unique in that they only appear once during a particular quest, but others consistently respawn. There are five of these monsters that have levels higher than your characters maximum level and it is these five I have left to beat (although I have not attempted them yet…).

Achievements: The game keeps track of your “achievements” as you progress through the game. These are separated into two types, Trials and Records. There are 50 Trials that basically cover working through all the collections above so if you are going to complete those then the Trials will get completed too. The 150 Records involve things like defeating a certain type of enemy a given number of times, using a given type attack a certain number of times, raising Skill and Arts to maximum levels and collecting crystals and crafting them into gems (an area of the game that is full of mystery as far as I am concerned…). Many of these fall into the tedious repetition category so I still have about 30 to complete.

That is a lot of stuff to do… As I said above, it will take substantially more than 100 hours if you want to do all of this. But I say it is definitely time well spent.

Many months ago I noticed that I logged into my blog over plain HTTP and thought to myself that I really must do something about that one day. And that day is… well… a couple of days ago! I honestly was never really too concerned about logging in insecurely as the chances of anyone actually wanting to gain access to this blog and being in a position to exploit the insecure login is minimal. My guess would be that the majority of self-managed WordPress installs are administered over plain HTTP.

So apart from general apathy, what kept me from fixing this? Cost was probably the main issue… Any cost for a SSL certificate would not be particularly justified in my case. I also did not want to use a self-signed certificate as I find the security warnings that all web browsers give about untrusted certificates annoying enough to not want them on my site. That also rules out the free SSL certificates from CAcert, as the CAcert root certificate is not included by most browsers by default.

Then I saw a post somewhere about the free certificates given out by StartSSL. The price is right and the root certificate is commonly included so all seems good. There is not much actual validation that goes on to get one of these – my email and domain name were “verified” by sending emails… – so they would not be good for any site where trust is actually needed (such as anything where any personal and financial data are being collected).

Once validated, all I had to do was provide a CSR and they provided me the certificate. My webhost then uploaded that certificate and broke everything! The HTTPS version of my site was giving the error “ssl_error_rx_record_too_long”, which is actually quite uninformative as it covers a wide range of actual issues, and the HTTP version for some reason lost all access to files even thought they were clearly still there when I checked. This took me a few hours to notice as I had to wait for the DNS entries to propagate, so the issue was reported at 5pm on Friday the 30th of December… I really thought my website would be down until the 3nd of January when the support desk reopened, but everything was fixed a few hours later. So good service given what I pay, but the whole issue could have been avoided with a simple check at their end once the SSL certificate was installed.

Once you have your SSL certificate installed and ready to go, making WordPress enforce SSL usage for all administration tasks is simple. Simply add the following to your wp-config.php file:

define('FORCE_SSL_ADMIN', true);

Now all your blog administration is secure(ish). The final thing to do was to check whether browsing my website using HTTPS worked… No, it did not! I was getting messages about the site only being partially encrypted. A quick search showed I serve all my images using the full URL rather than a relative one. I did this because a certain Linux distribution’s Planet feed did not show images otherwise (or at least that was the case a long time ago – I have not tested lately). I could go through and adjust all my image links to use HTTPS, or just disable HTTPS access to my website. I chose the latter as nothing on my site is that important that it needs to be encrypted and I thought it would be the quicker option… Several hours later and this is the rule you need to add to your .htaccess file to achieve this:

RewriteCond %{ENV:HTTPS} on [NC]
RewriteRule !^wp-(admin/|login.php|includes/|content/)(.*)$ http://allanmcrae.com%{REQUEST_URI} [R,L]

The only real trick there is that the WordPress login and administration interface uses files from the wp-includes and wp-contents directories so they need to be excluded from the RewriteRule.

So… remember how I said self-signed certificates were annoying as all visitors to the site would get a warning. Well, now I force HTTP usage, that whole argument is irrelevant as only I would see the SSL certificate when I access the administration interface. But I at least have the option of serving parts of the site over HTTPS using a recognized certificate if I ever feel the need.

I have previously covered the more technical aspects of the implementation of PGP signing of packages and repository databases in pacman. You can read the previous entries here:

• Part 1: Makepkg and Repo-add
• Part 2: Pacman-key
• Part 3: Pacman

Since then, pacman-4.0 has been released and has been in the [testing] repository in Arch Linux for a while. That means that the signing implementation is starting to get some more widespread usage. No major issues have been found, but there are some areas that could be improved (e.g. the handling of the lack of signatures when installing packages with -U – FS#26520 and FS#26729). And it has successfully detected a “bad package” in my repo… (well, not really a bad package, but a bad signature. Lesson: do not try creating detached signatures for multiple files at once because gnupg is crap…).

The Arch repos have been gradually preparing for the package signature checking in pacman-4.0. Support for uploading PGP signatures with packages was added in April and was made mandatory from the beginning of November. As of today, 100% of the packages in the [core] repo and approximately 71% of [extra] and 45% of [community] are signed.

So all the components are coming together nicely. But how does this work from a practical standpoint? I’ll start with setting up the pacman PGP keyring and pacman.conf.

When first installing pacman-4.0, you should initialize your pacman keyring using pacman-key --init. This creates the needed keyring files (pubring.gpg, secring.gpg) with the needed permissions, updates the trust database (obviously empty at this point…), and generates a basic configuration file. It also generates the “Pacman Keychain Master Key”, which is your ultimate trust point for starting a PGP web of trust. You may want to change the default keyserver in the configuration file (/etc/pacman.d/gnupg/gpg.conf) as some people have issues connecting to it.

The set-up of your pacman.conf file is somewhat a matter of personal preference, but the values I use are probably reasonable… I have the global settings for signature checking as the default value (Optional TrustedOnly). This basically sets the need for signatures to be optional, but if they are there then the signature has to be from a trusted source. See the pacman.conf man page for more details. For the Arch Linux repos with all packages signed, I set PackageRequired which forces packages to be signed but not databases. (For the small repo I provide, I use Required as both packages and databases are signed.)

Lets look at some output when installing a signed package:

# pacman -S gcc-libs
warning: gcc-libs-4.6.2-3 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...
 
Targets (1): gcc-libs-4.6.2-3
 
Total Installed Size: 2.96 MiB
Net Upgrade Size: 0.00 MiB
 
Proceed with installation? [Y/n]
(1/1) checking package integrity [######################] 100%
error: gcc-libs: key "F99FFE0FEAE999BD" is unknown
:: Import PGP key EAE999BD, "Allan McRae ", created 2011-06-03? [Y/n] y
(1/1) checking package integrity [######################] 100%
error: gcc-libs: signature from "Allan McRae " is unknown trust
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.


As you can see, pacman struck a package that had a signature from an unknown key. It then asks if you would like to import that key. Given the PGP key fingerprint matches that published in multiple places, importing that key seems fine. Then pacman errors out due to that key not being trusted. Well, that Allan guy seems reasonably trustworthy… so I could just locally sign that key using pacman-key --lsign EAE999BD and that key will now be trusted enough to install packages.

Validating every Arch Linux Developer’s and Trusted User’s PGP key would soon become annoying as there are a fair number of them (35 devs and 30 TUs – with some overlap). To make this (a bit…) simpler, five “Master Keys” have been provided for the Arch Linux repositories. The idea behind these keys is that all developer and TU keys are signed by these keys and you only need to import and trust these keys in order to trust all the keys used to sign packages. These key fingerprints will be published in multiple places so that the user can have confidence in them (see the bottom of this post for a listing of the fingerprints obtained relatively independently of those listed on the Arch website).

To set-up your pacman keyring with these keys, you can do something like:

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
    pacman-key --recv-keys $key
    pacman-key --lsign-key $key
    printf 'trust\n3\nquit\n' | gpg --homedir /etc/pacman.d/gnupg/ \
        --no-permission-warning --command-fd 0 --edit-key $key
done


That will import those keys into your keyring and locally sign them. But that is not quite enough as those keys are not used to sign packages themselves. In order for pacman to trust PGP keys signed by the master keys you have to assign some level of trust to the master keys. The final line gives the master keys “marginal” trust. Note I use gpg directly rather than pacman-key as pacman-key does not understand the --command-fd option. You could use pacman-key --edit-key if you wanted to manually type in the commands to set the trust level. By default, the PGP web of trust is set up such that if a key is signed by three keys of marginal trust, then that key will be trusted. (We have five master keys rather than the minimal three so that we can revoke two – a worst case scenario… – and still have our packages trusted.) Note that setting the master keys to have marginal trust serves as a further safety mechanism as multiple keys would need to be hijacked to create a key that is trusted by the pacman keyring.

Now that the five master keys are nicely imported into your pacman keyring, any time pacman strikes a package from the Arch Linux repos with a signature from a key it does not know, it will import the key and it will automatically be trusted. At least that is the idea… We are still in a transition period so not all Developer and Trusted User keys are fully signed yet by the master keys yet, but we are not too far off. In the future we might provide a pacman-keyring package that streamlines this process a bit, or at least will save the individual downloading of each packager’s key.

That just leaves the signing of the databases, but that is a story for another day!

–
Arch Linux Master Key fingerprints:
    Allan McRae – AB19 265E 5D7D 2068 7D30 3246 BA1D FB64 FFF9 79E7
    Dan McGee – 27FF C476 9E19 F096 D41D 9265 A04F 9397 CDFD 6BB0
    Ionuț Mircea Bîru – 44D4 A033 AC14 0143 9273 97D4 7EFD 567D 4C7E A887
    Pierre Schmitz – 0E8B 6440 79F5 99DF C1DD C397 3348 882F 6AC6 A4C2
    Thomas Bächler – 6841 48BB 25B4 9E98 6A49 44C5 5184 252D 824B 18E8

Well… sort of…

The Brisbane City Council organizes a kerbside collection a couple of times a year for large items that you are unable to put in your rubbish bin. So given the dead state of my lawnmower, this seemed the ideal opportunity to get rid of it.

Now, one person’s garbage is someone else’s treasure… so quite a lot of stuff put on the side of the road is taken away before it is collected. While dragging the lawnmower up my driveway to the side of the road, the wheel I repaired fell off again (which is obviously no reflection on the quality of my workmanship). I guess someone saw the lawnmower and thought that was the only issue with it and took it. I think they will be in for a shock (potentially literally) when they plug it in later.

Keep an eye out for lawnmower related electrocutions in the Brisbane media over the next few days….

It is with great sadness I have to inform you of the passing of Ozito “Oz” Lawnmower (2006-2011). His tragic demise occurred a couple of months ago in a ball of blue electrical sparks, possibly as a result of exposure to rain… The case for criminal proceedings (negligent homicide) was investigated, but the current punishment of having to use a push mower to maintain the lawns has been concluded to be adequate.

I know what my readership wants to hear, so lets talk tech specs! Oz had a 1100W induction motor powered by 230V of electricity at 50Hz. He would cut at a maximum 3000rpm in a counter clockwise direction at the heights of either 31, 47 or 63 mm and with a cutting diameter of 320mm. All this while producing only 96dB of noise.

From his birth somewhere in China, Oz had a tough life. His first assignment was a relatively nice piece of lawn, but it came with the risk of a collapsing retaining wall and so he lived in fear of being horribly crushed. Luckily that assignment did not last long, but his second and final one was potentially much worse. Initially the new “lawn” he was sent to mow was nothing much more than a collection of weeds (including some that he just could not handle). This resulted in one of his wheels suffering from a mild detachment issue that required constant attention.

Just when his job was looking up due to the clearing and turfing of the entire lawn area, tragedy struck. His wheel came loose and went underneath his blade and was completely destroyed. Much searching was made for a replacement and the end of a drainage pipe was even being considered, when I was told by the helpful man at the hardware store that he had just the thing to fix it… a lawnmower wheel. And so, with the help of a hammer and a piece of wood, Oz got a new wheel attached and was looking forward to working until retirement on a nice patch of grass. Unfortunately, life was not so kind.

And so the tale of the life of Ozito comes to its end. He will be sadly missed.

And on with the “final” component of the package signing saga… I have previously posted about signing packages and databases and managing the PGP keyring, which was all preparatory work for pacman to be able to verify the signatures.

In the end, most people will not notice pacman verifying signatures unless something goes wrong (at least once it is configured). You will see the same “checking package integrity” line, but instead of verifying the packages md5sum, the PGP signature will be checked if available. But implementing this required substantial reworking of the libalpm backend, with the adding of signature verification abilities through the use of the gpgme library, adding flexible configuration options to control repo and package signature verification, changes to how and when repo databases get loaded (so that we can error out early if the repo signature is bad), and the list goes on… The majority of this was done by Dan McGee, who is the lead pacman developer. In fact, looking at the git shortlog for this development cycle:

$ git shortlog -n -s --no-merges maint..
   296  Dan McGee
   128  Dave Reisner
   124  Allan McRae
   ...
(followed by 18 other contributors with 11 or less commits each). So Dan takes the clear lead with about 50% of all commits in this developmental cycle, while the battle for second place remains intensely competed for!

So what have we ended up with? My opinion is ever so slightly biased, but I think we have ended up with the most complete and flexible package signing implementation yet. Most other package managers signature checking is simply a call to gpgv, which trusts any signature in your keyring. With the more complicated solution using gpgme, pacman has the complete concept of the web of trust, allowing for very precise keyring management. We not only sign packages, but sign databases too. Importantly, we can add expiry times to those signatures, which together prevents a malicious mirror holding back individual package updates or deliberately not providing any updates at all. As an aside, we also now protect against the “endless data attack” where an attacker sends an endless data stream instead of the requested file. Together that covers the most well reported avenues of attack on package managers (I hesitate to say “all” despite not knowing of any others because someone will prove me wrong!).

Onward to the actual use of signature checking in pacman. The main adjustment needed to be made is the addition of the SigLevel directive to pacman.conf. This can be specified at a global level and also on a per-repo basis. The SigLevel directive takes three main values: Required, which forces signature checking to be performed; Optional (default), which will check signatures if present but unsigned packages and databases will be accepted; and Never, which sets no signature checking to be preformed. More fine grained control can be added by prefixing these options with Database and Package and combining multiple options. For example, I have a local repo that has a signed database but not all packages have signatures. So I use SigLevel = Optional for my global default and add SigLevel = DatabaseRequired to enforce the database to be validly signed for that repo. Alternatively, I could use SigLevel = DatabaseRequired PackageOptional to explicitly achieve the same result. You can also specify the level of trust needed in a signing key using the TrustedOnly (default) and TrustAll options. The former will only accept a key if it is fully trusted by your PGP keyring, while the latter only requires the key to be present in the keyring (much like using gpgv).

As I wrote earlier, there is very little change from a users perspective once configured. About the only thing that is really noticeable is that pacman will attempt to download a signature for each database it downloads when the database SigLevel is set to Required or Optional. For example:

$ pacman -Syu
:: Synchronizing package databases...
 allanbrokeit           1464.0B  540.5K/s 00:00:00 [######################] 100%
 allanbrokeit.sig        287.0B    7.0M/s 00:00:00 [######################] 100%
...

Beyond that, the checking of PGP signatures occurs during the usual package integrity check stage so will go largely unnoticed unless something goes wrong. This is both a good thing (we all like pacman because of its simplicity) and a bad thing (as the large amount of work done here is not particularly visible to the user). So when everything with package are repo database signing just works for you, remember to thank your local pacman developer (and if it all goes wrong, it was not our fault…).

While I have not actually posted anything on my Google+ account yet, I am fairly awesome at time wasting and that makes the addition of games there a fairly attractive prospect. We all know that these games are designed to make the publishers some money and demonstrate (a.k.a. take advantage of in order to make money…) the social aspect of Google+. However, I am not willing to pay money or be social… So, with those restrictions, here is opinions on the currently available games.

Zynga Poker – I like poker, so this game was the first I tried. The good thing about it is that you can use it as a completely free poker client and just play poker. All the extra social crap is optional and does not really get in the way too much. However, there are better poker clients out there with freeplay and they have many more players (I never got to play a “sit and go” match once due to lack of people to form a table). Also, I like to have more than one table running at a time or the waiting gets boring.

Monster World – This almost set of my “Gotta Catch ‘Em All” urge. But it had one fatal flaw. I planted my fields full of an expensive plant that takes 16 hours to grow. But there is absolutely nothing in the game to do while you wait for that 16 hours. So essentially the game is forcing you not to play the game, which I think amounts to the stupidest concept in game design ever.

Angry Birds – I have never really been a fan of this game so I did not spend much time playing it. While it appears that some parts of the game would require teaming up with friends, there is enough single player gameplay to keep you entertained for a decent amount of time.

Dragon Age Legends – This seemed like a game I would like, but I just could not enjoy it for some reason. I think part of my issue was with the graphics. I know these games are not supposed to be graphics powerhouses, but when limited in that department I often think you are better off going very simple and refined. Everything in this game, but especially the characters, just looked horrid.

Diamond Dash & Collapse! Blast – Both these games have the very annoying “feature” that you lose a life for each round you play. And these rounds only last one minute, so you very quickly run out of lives. At that point, the best thing to do is to shut down the game and wait for time to pass so that lives are replenished.

Crime City & Zombie Lane – Like the above games, but instead of running out of lives, you run out of energy and can not do anything. I also did not get what the fun was in Crime City. All you did was click your mouse on the green arrow and wait for a progress bar to fill up.

Bubble Island – I only played the first five or so level sets on this so never actually lost a life. But from what I can see, if I did fail it would require me playing previous levels 500 times to get a retry attempt. That is equivalent to locking you out of the game as far as I am concerned.

Wild Ones – Worms clone with dogs… and as far as I could tell, completely useless single player.

City of Wonder, Dragons of Atlantis & Edgeworld – I dislike any click a building, watch it build, research upgrades, real time strategy type game. And I can not imagine them becoming better with an inability to right click on anything…

Bejeweled Blitz – Meh, Bejeweled… but this is one of the few games where not being willing to pay or be social has very little effect.

Flood It – Puzzle game that I could not find where the fun was located.

Sudoku Puzzles – Not a game… I completed one board to see if there was some sort of side challenge or something to actually make this a game, but failed to see the game part.

Now that I have decided that all these games are basically crap, I would like to clear all of what I have done from the game providers server. But unless I am missing something, not a single game appears to have the option to delete your progress. This is a bit of a surprise given one of the main selling points of Google+ over its competition was the ability to completely control your information, but I guess that does not extend to third parties. So that information you gave the provider authorization to access at the start of the game is permanently in their hands. While Google appears to have done the good thing and allows you to revoke access to your information (under “Account Settings” -> “Account Overview” -> “Security” -> “Authorizing applications & sites”), in reality that will only stop access to new changes you make to your profile as the game providers will already have your data stored. I would be interested in seeing if deleting your Google+ account completely removed your scores etc from the people in your circles games.

In this second part of the ongoing series of articles about the implementation of package signing in pacman, I am going to focus on keyring management and the new tool pacman-key that is provided to help with this. You can read the previous entry covering makepkg and repo-add here.

The way in which the PGP keyring for pacman is managed will be an essential aspect of the security of your system. The keyring (in combination with configuration options for pacman itself), will control which package and database signatures that you trust and thus what packages get onto your system. In fact, I’m still not entirely sure how best to set-up the keyring in terms of importing keys and setting their trust levels as the only repo I currently use that has full signing is my own and for that I can just add my own key with ultimate trust. Adding my key with ultimate trust would not be ideal for other people to do, but then again it may be acceptable given it is in a keyring for pacman only. But this is more the social aspect of PGP signing so I will leave discussing that further to another time.

However the keyring is set-up, it is helpful to have a tool to manage it. While this could be done directly using gpg with the --homedir flag, there are a few pacman specific keyring management issues that warranted the creation of a separate tool. Enter pacman-key. Originally this was a port of Debian’s apt-key to pacman by Denis A. Altoé Falqueto, but has slowly become closer to being just a gpg wrapper with additional functions. I’ll also add a shout-out to both Ivan Kanakarakis and Pang Yan Han who also contributed multiple patches towards this script and Guillaume Alaux who provided the initial man page.

The pacman keyring will be located (by default) in /etc/pacman.d/gnupg (although this can be adjusted using the GPGDir directive in pacman.conf). The keyring should be set-up using pacman-key --init to ensure the files have the correct permissions for full pacman signature checking functionality. For example, to verify package signatures as a user (e.g. using pacman -Qip <pkg>), we need to let the user have read permissions on the keyring files and also add a gnupg configuration file to prevent the creation of a lock file (this is currently required to be done globally as the gpgme library used by pacman does not have the ability to control lock file creation…).

Keys can be added to the pacman keyring in several ways. They can be imported from a local file or files using pacman-key -a/--add <file(s)> or from a public key server using pacman-key -r/--receive <keyserver> <keyid(s)>. You can also --import entire sets of keys and trust dbs from other gnupg keyrings you have. Keys are removed using the -d/--delete option. There is also a mechanism for a distribution or other repo provider to supply a keyring containing all their packagers’ PGP keys to be imported into the pacman keyring, but this area is still undergoing development.

Once you have some keys in your keyring, you can manipulate them using pacman-key and some standard gnupg flags including --edit-key, --export, --list-{keys,sigs}, etc. The --edit-key option is fairly important as it allows you to do things like adjust the trust levels or locally sign keys in the keyring, which builds our web of trust. For any more advanced manipulation of the keyring (or just something that is not wrapped by pacman-key), you need to use gpg directly (although I am sure that if it turns out that a commonly used command is not currently wrapped by pacman-key, it can be added on request…).

And that is basically all there is to the pacman-key tool. It is fairly simple but it is also the part of the package signing implementation that has probably received the lowest volume of testing as it is not a script that will be used everyday. If you would like to help test it out while not touching your system pacman, you can build and run it directly from a git checkout. This should get you there:

$ git clone git://projects.archlinux.org/pacman.git
$ cd pacman
$ ./autogen.sh
$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
$ make -C scripts
$ ./scripts/pacman-key

Test initializing a new keyring, adding and removing keys, editing a keys trust level, verifying a file with a detached signature (many packages in the Arch repos are already signed) and report any issues you run into.

For those using my simple MacBook Pro fan daemon, you probably want to check that it still works… At least on my system, the location of the core temperature measurements have changed from /sys/devices/platform/coretemp.{0,1}/temp1_input to /sys/devices/platform/coretemp.0/temp{2,3}_input. I think this occured with the update to Linux 3.0 (but I am too lazy to confirm that is the actual update to blame…).

If you also have this change, you can grab an updated version of the daemon here. As always, it is only tested on my machine (MBP 5.5 13″), so it may not work anywhere else without adjustment…