Miscellaneous ephemera…

pass{,word} manager

After posting last week about KeePassC as a password manager, a couple of people immediately commented about a utility billed as “the standard Unix password manager.” This is definitely one of the reasons I continue to write up my experiences with free and open source software: as soon as you think that you have learned something, someone will either offer a correction or encourage you to explore something else that is similar, related or interesting for some other tangential reason.

So, I was off down that path… Called simply pass, it is a 600 line bash script that uses GPG encryption and some other standard tools and scripts to organize and manage your password files. I had never heard of it but, based on Cayetano and Bigby’s recommendations, I thought it would be worth a look.

On of the reasons that I had not come across it before was that, after using KeePassX for so long, I had assumed that I would need to continue to use that database format; so when I was looking for an alternative, KeePassC was a natural fit (and a fine application). The question of migrating my data hadn’t even occurred to me…

It turns out that the migration process to pass is extraordinarily well catered for: there are 10 migration scripts for a range of different formats, including keepassx2pass.py, which takes the exported XML KeePassX database file and creates your pass files,ordered by the schema you had used in that application. You just need to make sure you amend the shebang to python2 before running the script, otherwise it will fail with an unhelpful error message.

After using KeePassX to dump my database, before I could use the script to create my pass directories, I had to export the PASSWORD_STORE_DIR environment variable to place the top level pass directory in an alternate location. This way, instead of initializing a git repository, I could have the store synced by Syncthing. The git idea is a good one, but I’m not particularly interested in version controlling these directories, and I have no intention, encrypted or not, of pushing them to someone else’s server.

That constitutes the basic setup. It took a grand total of five minutes. The real strength of pass, however, is in its integration with two other fantastic tools: keychain and dmenu. Together with pass, these constitute a secure, convenient and effortless workflow for managing your passwords. With your GPG key loaded into keychain, you are only prompted for your master passphrase once1 and with Chris Down’s excellent passmenu script, you can use dmenu to sort through your password files, Tab complete the one you are looking for and have it copied to your clipboard with a couple of keystrokes.

After using Chris’ script for a couple of days, I made a few alterations to suit my setup: removed the xdotool stuff (as I don’t need it), included dmenu formatting options to match my dwm statusbar and, most significantly, changed the way that the files are printed in dmenu to remove the visual clutter of the parent directories, ie., print archwiki as opposed to internet/archwiki:

#!/usr/bin/env bash
# based on: https://github.com/cdown/passmenu

shopt -s nullglob globstar

font="Dejavu Sans Mono:medium:size=7.5"
dmenucmd=( dmenu -i -fn "$font" -nb "$nb" -nf "$nf" -sb "$sb" -sf "$sf" )

files=( "$prefix"/**/*.gpg )
files=( "${files[@]#"$prefix"/}" )
files=( "${files[@]%.gpg}" )
fbase=( "${files[@]##*/}" )

word=$(printf '%s\n' "${fbase[@]}" | "${dmenucmd[@]}" "$@")

if [[ -n $word ]]; then
  for match in "${files[@]}"; do  
    if [[ $word == ${match#*/} ]]; then
      /usr/bin/pass show -c "$match" 2>/dev/null

It does introduce some more complexity into the script, but it makes it a lot easier for me to identify the desired password when reading it in dmenu.

Now, when I need a to enter a password, I hit my dmenu hotkey, type dpass Enter and the first couple of letters of the desired password filename, TabEnter and the password is loaded and ready to go. There are also completion scripts for the main shells, and even one for fish2 for the iconoclasts…

While I has no complaints at all with KeePassC, I have found this pass setup to be a lot less intrusive to use, it seamlessly integrates with my workflow, and the passwords themselves are much simpler to manage. Short of someone else popping up in the comments with another compelling proposition, I’m content with the way this has worked out. Many thanks to Cayetano Santos and Bigby James for the push.


  1. There is a very annoying bug open for keychain that means if, as I do, you start keychain from your $HOME/.profile or $ZDOTDIR/.zprofile you will need to enter the same passphrase to unlock a sub-key before you can use pass (the same thing applies to Mutt). This gets really ugly if you attempt to use dmenu before unlocking your key…
  2. Finally, a command line shell for the 90s… Indeed.

Creative Commons image by Intel Free Press on Flickr.

CLI Password Manager

Managing passwords is a necessary evil. You can choose a number of different strategies for keeping track of all of your login credentials; from using the same password for every site which prioritises convenience over sanitysecurity, through to creating heinously complex unique passwords for every service and then balancing the relief of knowing your risks of being hacked have been minimised with the very real fear you will only remember any of them for a short period—if at all—and will shortly be locked out of everything.

Fortunately, this is a solved problem. There are a number of password managers available, both as desktop clients and cloud services. Personally, I find the idea of storing my passwords in the cloud has all the fascination of bungee jumping; it’s apparently mostly safe, but that can be cold comfort… The first application that I used, and used happily for quite a long time, was KeePassX.

Around the end of 2012, I started experimenting with KeePassC, a curses-based password manager that is completely compatible with KeePassX and has very little in the way of dependencies. I have been using it solidly on my home and work laptops ever since and, after recently uninstalling Skype on my desktop, have switched over to it completely1. I’m still not entirely clear why I haven’t written about it previously.

Written in Python 3, KeePassC is entirely keyboard driven (naturally enough, you can use Vim keybinds) and integrates seamlessly with your browser and clipboard. My experience of the software over the last eighteen-odd months is that it has been incredibly stable and the developer, Karsten-Kai, has been exceptionally responsive and helpful in the forum thread.

Like most good software, there is not a lot to it. You pull up the login page, switch to a terminal and run keepassc, enter your passphrase (I use a Yubikey for this and it works wonderfully) and then search for your desired entry with / and then hit c to copy the password to your clipboard before switching back to the browser and you are in.

KeePassC also has a set of simple command line options, run keepassc -h to see them. Additionally, you can set up KeePassC as a server, I haven’t experimented with this as I sync my database. The only functionality that the X application offers in addition, as far as I can tell, is the auto-filling of your username and password fields bound to a keybind; undoubtedly, this is a very handy feature, but I haven’t really missed it at all.

As I said, I store the database in a directory synced between all my machines2 (using Syncthing), so I have access to an up-to-date versions of my credentials everywhere. Well, almost everywhere. I don’t use the Android client because the mobile web is just such a fundamentally insecure environment and I see it as just being sensible, rather than any sort of inconvenience.


  1. Skype and KeePassX were the only two applications I used that required Qt, so once Skype was gone there was no reason to keep KeePassX installed.
  2. And, after a nasty scare very early on with a corrupt database, I back that file up daily.

Creative Commons image on Flickr by xserv.

Install scripts

It is now almost exactly two years since the AIF was put out to pasture. At the time, it caused a degree of consternation, inexplicably causing some to believe that it presaged the demise of—if not Arch itself, then certainly the community around it. And I think it would be fair to say that it was the signal event that launched a number of spin-offs, the first of which from memory was Archbang; soon followed by a number of others that promised “Arch Linux with an easy installation,” or something to that effect…

Of course, if you look back at the Installation Guide immediately before the move to the new scripts, for example the version that shipped with the last AIF in October, 2011, it is pretty evident that the current approach is a lot simpler. Sure, there is no curses GUI to step you through each part of the install but the introduction of pacstrap and arch-chroot meant that you no longer need those prompts.

There is also the added advantage that these scripts are useful outside the installation process itself; they can be used for system maintenance and, in the rare event that your recent bout of experimentation at 2am after a few drinks doesn’t pan out the way you anticipated, repair.

One of the other responses to the new approach, however, has been the steady proliferation of “helpful” install scripts. These are essentially bash scripts that emulate the behaviour of the AIF and walk people through an automated install of their system. Well, not really their system, more accurately a system. So you run one of these scripts, answer a few prompts and then, when you reboot, you have a brand spanking new Arch Linux install running KDE with the full panoply of software and, in a few special cases, some customized dot files to “enhance” your experience.

From a certain perspective, I can see how these things appeal. “I wonder if I could script an entire install, from the partitioning right through to the desktop environment?” That sounds like a fun project, right? Where it all comes unstuck, unfortunately, is when the corollary thought appears that suggests sharing it with the wider community would be a good idea. It is at this point that a rigorous bout of self-examination about the outcomes that you are seeking and your base motivations for this act of selflessness are called for.

Whatever those motivations are, whether driven by altruism or the naked desire for fame and fortune that have—from time to time—alighted on these projects when they appear on /r/archlinux and the adoring throngs bestow their favours in equal measures of upvotes and bitcoin, they are grotesquely misplaced. No good comes from these things, I tell you; none.

Why not? Because, in the guise of being helpful, you are effectively depriving people of the single most important part of using Arch: building it themselves. It’s like inviting someone to a restaurant for an amazing haute cuisine meal, sitting them down across the table from you and then them watching as the staff bring out a mouth-watering array of dishes, each of which you ostentatiously savour before vomiting it all back into their mouth.

Now, I am sure there is a small minority (well, at least from my own sheltered experience I imagine it is small) who would relish this scenario, but for most it would qualify as a pretty disappointing date.

Then, after the technicolour table d’hôte, there is the matter of the clean up. Recently, we had someone show up on the Arch boards who had “installed Arch” but who did not understand how to edit a text file; literally had no clue how to open a file like /etc/fstab make some changes and then save it. This is beyond stupid; it is a drain on the goodwill of the community that has to deal with this ineptitude, it is unfair on people to put them in a position where they feel they are at the mercy of their technology, rather than in control of it, and it does nothing to advance the interests of Arch.

If you want to write something like this to improve your scripting skills, by all means proceed. If you want to contribute to Arch, then pick a project to contribute to, some bugs to squash, wiki edits, whatever; just don’t publish another one of these idiotic scripts, because you aren’t doing anyone any favours, quite the contrary.


Flickr Creative Commons image, Measuring spoons by Theen Moy.