With the torrent of recent revelations about the enthusiasm with which the governments of most of the first world have been systematically and unlawfully violating the privacy of their citizens by intercepting their digital communications, I thought it worth adding to the posts I have written about Mutt—that most peerless of email clients—specifically how, combined with GnuPG, you can encrypt all of your mail and ensure that the only person reading it is the intended recipient.

The definitive guide for this setup remains Justin Miller’s venerable page, Everything You Need To Know To Start Using GnuPG with Mutt, last edited in 2001 and still the authoritative source. The setup I will describe differs only insofar as it covers how to use multiple keys associated with different mail accounts. Mutt gives you the flexibility sign or encrypt all of the email in your work account with one key, and your personal email with another.

Once you have set up your GPG keys¹, the first step is to configure Mutt to use your keys. You can include these directives in your muttrc but, in the interests of readability, I prefer to split them out into gpg.rc and source them from muttrc. The settings are self-explanatory, those most relevant to this post control how mutt handles your mail with respect to encryption or just signing²:

1
2
3
4
5

set pgp_use_gpg_agent = yes
set pgp_sign_as = 43A5CE95
set pgp_timeout = 3600
set crypt_autosign = yes
set crypt_replyencrypt = yes

This sets my work key as the primary key and a couple of other sane (for me) defaults. All of these options are described in muttrc(5). You can see my complete file in my bitbucket repo.

The rest of the recipe is in muttrc:

1
2
3
4
5
6
7
8
9

source ~/.mutt/gpg.rc            # use GPG

# gpg key
send-hook "~f @catalyst.net.nz"  set pgp_sign_as=43A5CE95
send-hook "~f @jasonwryan.com"   set pgp_sign_as=B1BD4E40

# key binds
bind compose p  pgp-menu
macro compose Y pfy "send mail without GPG"

Sourcing the gpg.rc reads all the relevant options and then a series of send-hooks allow you to use specific keys for each of your accounts.

Now, when you receive encrypted mail, if your key agent is running, Mutt will decrypt your mail on the fly. Otherwise you will be prompted for your key phrase. Similarly, when you send email, it will by default be signed by the key associated with that account, and you can encrypt individual mail by bringing up the GPG menu in the compose screen by hitting p.

And for those friends and acquaintances you correspond with for whom encryption is the equivalent of white powder spilling from an envelope, you can always elect to send without any GPG by selecting Y to send the email.

These and a number of other interesting tips and macros are on the Mutt Wiki and are worth following up once you have the basics working. Like so much of this sort of software, it takes a little longer to set up exactly the way that you want it, but once you are done, it is good for decades…

Notes

1. A good introduction to this procedure is detailed in the Arch Wiki article.
2. This assumes that you do want to distinguish between the two; you could, of course, just encrypt everything—assuming that your correspondents were willing and able to decrypt it…

Creative Commons image by Intel Free Press on Flickr.

I was fortunate enough to be given a Raspberry Pi earlier this year and, naturally enough, have been running Arch ARM on it over the last several months. Initially, I was at somewhat of a loss as to what to do with it, so was just (under)using it¹ for a persistent IRC connection. I have now, with very little effort, set it up as a headless torrent box and it is working nicely.

As is generally the case, this involved little more than stitching together a few lightweight tools to accomplish the task. In this case, it is a combination of rtorrent (with the canvas-colour patch applied), surfraw and w3m for discovering torrents,² bittorrent sync and, optionally, a VPN.

I use a 16GB USB drive to act as storage for the device, and mount it at ~/Downloads via /etc/fstab; depending on the size of your SD card, this may be superfluous.

First a note on building packages; building anything on the Pi—with only 512MB RAM—is a protracted and thankless task. So if you intend to do more of this, or do it regularly, set up cross-compiling; you won’t regret the initial investment.

rtorrent is in the ARM repos, but I wanted to patch in colour, so I wrote a PKGBUILD, based on the package in [community] and ashren’s AUR package. Once you have rtorrent installed and working, the rest is straightforward.

The default config for w3m is perfectly functional, but can be easily customized further. The key to this setup is being able to find a torrent and then easily add it to rtorrent’s queue. To do this, I modified the hack that I wrote up a couple years back. Essentially, you use w3m’s external link function to trigger a script to grab the magnet link. Like so:

1

extbrowser /home/jason/Scripts/magnets %s

and the script from the rtorrent wiki:

1
2
3
4

#!/bin/bash
cd $HOME/Downloads/Queue/watch/    # set your watch directory here
[[ "$1" =~ xt=urn:btih:([^&/]+) ]] || exit;
echo "d10:magnet-uri${#1}:${1}e" > "meta-${BASH_REMATCH[1]}.torrent"

Remapping the w3m key to trigger the script to make it more Vim-like:

1

keymap Y EXTERN_LINK

And now hitting Shifty over a magnet link adds it to your queue.

The final piece was to ameliorate the step of transferring the completed files from the Pi, or for allowing me to add torrents remotely. To do this, I used a bittorrent sync shared directory as ~/Downloads. All files are synched to my desktop as they are downloaded to the Pi. Simple.

As I mentioned above, you could also use a VPN and, with a service file, have it connect on boot if you wished to further protect your privacy.

Notes

1. This is not to say that I am now using it to it’s full potential; quite the opposite. Recommendations or suggestions gratefully received.
2. Discovery is your business; what you choose to download and share may be the business of copyright holders…

Another great peristaltic movement in Arch’s rolling release digestive system happened over the last couple of weeks, the move of all binaries to /usr/bin. This move had been foreshadowed for several months and, despite announcements on the front page of the Arch website, the mailing lists and the release going through [testing] and the resulting thread on the forums, there was still a surprising amount of carnage¹ in it’s wake.

In the aftermath (although I expect that it will take some months for it to completely pass through the system), what struck me was not so much the variety and ingenuity of the ways people had managed to break their installs² as how they approached the community seeking help afterwards.

There are already some fine guides on how to do this, notably ESR’s How to ask Questions the Smart Way and—specifically for Arch—zendeavour’s troubleshooting for newcomers; this isn’t an attempt to add or expand on that genre. Rather, it is a look at a subset of attitudes that some people adopt³ as they seek the assistance of the community.

The first is the blamer. The proponent of the “all-guns-blazing” approach. I’ll paraphrase, but there are enough examples on the boards to illustrate the point: “my system can’t boot, it’s not my fault and I am here to let you know that I am unhappy and demand recourse.” This is, unquestionably, the most puzzling of all the strategies. It is often coupled with the (sadly almost always empty) threat to abandon the distro and it’s apparently beleaguered community.

Puzzling because I have yet to encounter a single situation in life, online or off, where opening with hostility and blame is an intelligent approach to seeking assistance. If you are going to adopt this approach, please supersize to “rage quit” and expend your energy actually delivering on your threat.

The next is the wheedler. Less objectionable than the incendiary approach, it is nonetheless similarly ineffective. Wheedlers are distinguished by peppering their posts liberally with declarations of their ineptitude and “noobness”, in the mistaken belief that this will engender a wave of sympathy prior to soothing hand-holding and spoon-feeding. There is a strong correlation between this behaviour and the various types of help vampirism.

Wheedling won’t lead to quicker, or more informed, advice and assistance; in all likelihood it will just discourage others from helping because they can see that rewarding this sort of behaviour has a longer-term deleterious impact on the health of the community.

Then there is the Vulcan. A curiosity more than an annoyance, these people seem to inhabit some sort of adolescent fantasy land where the Internet is a venue for them to revel in their almost superhero-like powers of technical awesomeness; said powers manifesting to others as a sort of benign cluelessness.

Their posts are invariably brief and completely devoid of relevant detail to the point of cryptic because, “hey, we all know what this issue is,” and are littered with smilies and that stupid emoticon with the sunglasses. Rather than actually describing their problem, they want people to think that, by a process of mind-melding, other “hackers” will intuit the subtle depth and intricacy of the issue and then type out a detailed step-by-step guide of how to solve it.

Finally, there is the conspiracist. These malcontents see every significant change in Arch as being part of a wider agenda to corrupt the purity of the UNIX® philosophy. They also tend to blame Lennart Poettering for everything. These unfortunates are clearly already suffering such mental anguish trying to reconcile their obsessiveness about the past with a rolling release that they deserve our pity more than our contempt (but I am equally happy providing either)…

As I said, these are fortunately just a subset and very much represent the minority of attitudes. The vast majority tend to be aware that, at one time or another, everyone will need some help to solve a problem. Therefore it is best to approach it in a matter-of-fact way, using the practical guidance on asking questions on a technical forum, and with a degree of humility and a willingness to learn from the people who are prepared to share their knowledge and experience.

Notes

1. Where “carnage” should be understood as a minor PEBKAC epidemia…
2. From shutting down mid-update (because a reboot fixes everything) to still using consolekit, initscripts and grub-legacy: all deprecated some time ago.
3. I resisted linking to specific posts on the boards to provide actual examples, the more motivated among you will find them without difficulty.

Flickr Creative Commons image by Buddhist Fox.