Review: The Emergency Sasquatch Ordinance, by Kevin Underhill

Publisher:	American Bar Association
Copyright:	2013
ISBN:	1-62722-269-3
Format:	Trade paperback
Pages:	334

First, if you have not read Lowering the Bar, you should do so. There aren't many blogs where I will start reading, end up reading numerous posts out loud to anyone in the vicinity, and then find myself systematically reading the entire backlog (which, in this case, is substantial). Kevin Underhill is a lawyer with civil libertarian leanings, a wicked sense of humor, and a knack for finding the most absurd legal stories. He varies between weary incredulity and caustic sarcasm, almost always manages to make me smile, and often makes me laugh out loud. The Emergency Sasquatch Ordinance, and Other Real Laws that Human Beings Have Actually Dreamed Up, Enacted, and Sometimes Even Enforced is, as one might expect, more of the same sort of thing that one gets from Lowering the Bar. However, unlike a lot of books released by long-standing bloggers, it is not a collection of previously published material. This is an entirely new collection of legal absurdities, drawing on history, US federal, state, and local law, and some non-US laws, and complete with Underhill's trademark commentary. Long-time readers of Lowering the Bar have seen several posts about this sort of thing before, which also means there's a great sample up on the web. See posts tagged "Law (Dumb)" for a preview of the sort of thing you'll get, although as mentioned the material in the book is original. My one complaint about the book version of this post type is that I think the blog posts tend to be longer and contain a bit more analysis. Underhill gets in about one punch line per law in the book, and I frequently wished for a somewhat longer analysis. The blog posts tend to get funnier and more biting once he works up a head of steam on a topic. The book is, alas, a bit uniform in its style. It's composed of a large number of "chapters," each of which is usually a page or two and covers a single law. Those are divided into ancient, pre-modern, US federal, US state, US city, and non-US laws, but with considerably funnier section headings than those. Each chapter has a title that's usually a brief summary of the law (often funny), an introduction, a quote (or several), and a punch line. There's not much variation, which makes it good bathroom reading you can pick it up anywhere, read a few pages, and put it back down without fear of losing context but lacks variety when read in large gulps. I find Lowering the Bar itself funnier than this book. I think that's because the blog posts are longer, more varied, and mix weird laws with caustic political commentary and entertaining stories of the extremely ill-advised things people do around, within, and against the law. The odd laws are entertaining; the stories of defendants, the accounts of weird legal proceedings, and Underhill's exasperated sarcasm about legal and political stupidities are even funnier. If you had to choose between the book and the blog, I'd go with the blog. That said, you don't have to choose, and if you've been reading the blog for a while, more material is always welcome. A book also has the substantial advantage of being a way to throw some money at a blogger as a reward for hours of entertainment, with a bonus of getting an enjoyable physical object in return. I certainly don't regret the purchase, and I've already had an opportunity to mention Millard Fillmore's State of the Union address on guano. I'm not sure if that means the book made me smarter, but I do believe it made me more entertaining. TL,DR version: Read Lowering the Bar. If you like that, there's this book. I think you can figure out the rest from there. Rating: 7 out of 10

I stared at Noodles' Emptiness, where I found a short rant on the currently most used forms of communication. No, into the most socially-useful forms of communication. No, into what works best for him. And, as each person's experience is unique, I won't try to correct him Noodles knows himself much, much, much, much better than I do. But some people have wondered recently (i.e. at conferences I have been at) why I give such an atypical use to social networks (...a term which I still hold to be grossly misused, but that's a topic for a different rant...One that's been had too many times). So, although my blog is syndicated at Planet Debian, and I know a good deal of readers come from there, this post is targetted at the rest of the world population: Those that don't understand why many among us prefer other ways of communication. Noodles mentions seven forms of communication he uses, arguably sorted by their nowadayness, low to high: Phone call, text (SMS) message, email, IRC, Skype, Google Hangouts and Facebook messenger. Among those, I strongly dislike two: Phone call and Skype (or any voice-based service, FWIW). I do most of my communication while multitasking, usually at work. I enjoy the quasi-real-timeliness of IRC and the instant messengers, but much more, I like the ability to delay an answer for seconds or minutes without it breaking the rules of engagement. Second, if the ordering is based on what I found, the reason for my little rant should become obvious: We had kept a great job so far building interoperable technology.1 Up until now, you could say drop me a mail , and no matter if you had your mail with GMail and I insisted on self-hosting my gwolf.org, as long as our communications adhered to simple and basic standards, we would be perfectly able to communicate. Skype is a bit of a special case here: They did build a great solution, ~ten years ago, when decent-quality VoIP was nowhere to be found. They have kept their algorithm and mechanisms propietary, and deliberately don't operate with others. And, all in all, there is a case for them remaining closed. But Google Hangouts and Facebook Messenger do piss me off. More the first than the second. Both arrived to the instant messenger scene long after the experimentation and early stages, so they both took Jabber / XMPP, a well tried and tested protocol made with interoperability and federability in mind. And... They closed it, so they can control their whole walled garden. So, yes, I do use them both Because in both there are many people which I value, and which I want to be in touch with. And no, I won't try to change the ways of everybody so they can talk with me on IRC. I'm an asshole, but everything has its limits! :) Of course, I can (still?) use them from my trusty old multiprotocol chat manager, Pidgin. And it's so much better to have one small program gobbling up moderate heaps of memory than to be connected to the Facebook site, spending much more memory and CPU cycles via Javascript in a Web browser. Bah. PS- Interestingly, he left out the face-to-face communication.I am quite an anchorite in my daily life, but I still think it's worth at least a mention ;-) So, Noodles: Thanks for the excuse to let me vent a rant ;-)

• 1. Interestingly, a counterexample came up on me. One I do not remember, but I have seen printed information that make me believe it: Back in the 1940s/1950s, Mexico (Mexico City only perhaps?) had two parallel phone networks. If I'm not mistaken, one was Ericsson and the other was AT&T. Businesses often gave you both of their numbers in their ads, because you could not call one network from the other. And now that seems so backwards and unbelievable!

I've been working on my backup strategy for the notebook recently. The idea is to have full backups every now month and then incremental backups in between as fine-grained as possible. As it's a mobile device there's no point in time where it is guaranteed to be up, connected and within reach of the backup server. As I'm running Debian GNU/kFreeBSD on it, using ZFS and specifically zfs send comes quite naturally. I'm now generating a new file system snapshot every day (if the notebook happens to be online during that day) using cron.

@daily zfs snapshot base/root@ date -I 
@daily zfs snapshot base/home@ date -I 
@reboot zfs snapshot base/root@ date -I 
@reboot zfs snapshot base/home@ date -I 

When connected to the home network I'm synchronizing off all incrementals that are not yet on the backup server. This is using zfs send together with gpg to encrypt the data and then put it off to some sftp storage. For the first snapshot every month a full backup is created. As there doesn't seem to be a way to merge zfs send streams without importing everything in a zfs pool I create additional incremental streams to the first snapshot of last month so I'm able to delete older full backups and daily snapshots and still keep coarse-gained backups for a longer period of time.

#!/usr/bin/python
# -*- coding: utf-8 -*-
####################
# Config
SFTP_HOST = 'botero.siccegge.de'
SFTP_DIR  = '/srv/backup/mitoraj'
SFTP_USER = 'root'
ZPOOL     = 'base'
GPGUSER   = '9FED5C6CE206B70A585770CA965522B9D49AE731'
#
####################
import subprocess
import os.path
import sys
import paramiko
term =  
    'green':  "\033[0;32m",
    'red':    "\033[0;31m",
    'yellow': "\033[0;33m",
    'purple': "\033[0;35m",
    'none':   "\033[0m",
     
sftp = None
def print_colored(data, color):
    sys.stdout.write(term[color])
    sys.stdout.write(data)
    sys.stdout.write(term['none'])
    sys.stdout.write('\n')
    sys.stdout.flush()
def postprocess_datasets(datasets):
    devices = set([entry.split('@')[0] for entry in datasets])
    result = dict()
    for device in devices:
        result[device] = sorted([ entry.split('@')[1] for entry in datasets
                                    if entry.startswith(device) ])
    return result
def sftp_connect():
    global sftp
    host_keys = paramiko.util.load_host_keys(os.path.expanduser('~/.ssh/known_hosts'))
    hostkeytype = host_keys[SFTP_HOST].keys()[0]
    hostkey = host_keys[SFTP_HOST][hostkeytype]
    agent = paramiko.Agent()
    transport = paramiko.Transport((SFTP_HOST, 22))
    transport.connect(hostkey=hostkey)
    for key in agent.get_keys():
        try:
            transport.auth_publickey(SFTP_USER, key)
            break
        except paramiko.SSHException:
            continue
    sftp = paramiko.SFTPClient.from_transport(transport)
    sftp.chdir(SFTP_DIR)
def sftp_send(dataset, reference=None):
    zfscommand = ['sudo', 'zfs', 'send', '%s/%s' % (ZPOOL, dataset)]
    if reference is not None:
        zfscommand = zfscommand + ['-i', reference]
    zfs = subprocess.Popen(zfscommand, stdout=subprocess.PIPE)
    gpgcommand = [ 'gpg', '--batch', '--compress-algo', 'ZLIB',
                   '--sign', '--encrypt', '--recipient', GPGUSER ]
    gpg = subprocess.Popen(gpgcommand, stdout=subprocess.PIPE,
                                       stdin=zfs.stdout,
                                       stderr=subprocess.PIPE)
    gpg.poll()
    if gpg.returncode not in [None, 0]:
        print_colored("Error:\n\n" + gpg.stderr, 'red')
        return
    if reference is None:
        filename = '%s.full.zfs.gpg' % dataset
    else:
        filename = '%s.from.%s.zfs.gpg' % (dataset, reference)
    with sftp.open(filename, 'w') as remotefile:
        sys.stdout.write(term['purple'])
        while True:
            junk = gpg.stdout.read(1024*1024)
            if len(junk) == 0:
                break
            sys.stdout.write('#')
            sys.stdout.flush()
            remotefile.write(junk)
        print_colored(" DONE", 'green')
def syncronize(local_datasets, remote_datasets):
    for device in local_datasets.keys():
        current = ""
        for dataset in local_datasets[device]:
            last = current
            current = dataset
            if device in remote_datasets:
                if dataset in remote_datasets[device]:
                    print_colored("%s@%s -- found on remote server" % (device, dataset), 'yellow')
                    continue
            if last == '':
                print_colored("Initial syncronization for device %s" % device, 'green')
                sftp_send("%s@%s" % (device, dataset))
                lastmonth = dataset
                continue
            if last[:7] == dataset[:7]:
                print_colored("%s@%s -- incremental backup (reference: %s)" %
                              (device, dataset, last), 'green')
                sftp_send("%s@%s" % (device, dataset), last)
            else:
                print_colored("%s@%s -- full backup" % (device, dataset), 'green')
                sftp_send("%s@%s" % (device, dataset))
                print_colored("%s@%s -- doing incremental backup" % (device, dataset), 'green')
                sftp_send("%s@%s" % (device, dataset), lastmonth)
                lastmonth = dataset
def get_remote_datasets():
    datasets = sftp.listdir()
    datasets = filter(lambda x: '@' in x, datasets)
    datasets = [ entry.split('.')[0] for entry in datasets ]
    return postprocess_datasets(datasets)
def get_local_datasets():
    datasets = subprocess.check_output(['sudo', 'zfs', 'list', '-t', 'snapshot', '-H', '-o', 'name'])
    datasets = datasets.strip().split('\n')
    datasets = [ entry[5:] for entry in datasets ]
    return postprocess_datasets(datasets)
def main():
    sftp_connect()
    syncronize(get_local_datasets(), get_remote_datasets())
if __name__ == '__main__':
    main()

Rumors have it, btrfs has gained similar functionality to zfs send so maybe I'll be able to extend that code and use it on my linux nodes some future day (after migrating to btrfs there for a start).

I've written a small dmenu-based script which allows to select passwords from one's pass password manager and have it xdotool typed in. This should completely bypass the clipboard (which is distrusted by people for a reason). As I've been asked about the script a few times in the past here it is. Feel free to copy and any suggestions welcome.

#!/bin/bash
shopt -s nullglob globstar
list_passwords()  
	basedir=~/.password-store/
	passwords=( ~/.password-store/**/*.gpg )
	for password in "$ passwords[@] "
	do
		filename="$ password#$basedir "
		filename="$ filename%.gpg "
		echo $filename
	done
 
xdotool_command()  
	echo -n "type "
	pass "$1"
 
selected_password="$(list_passwords 2>/dev/null  dmenu)"
echo $selected_password
if [ -n "$selected_password" ]
then
	xdotool_command "$selected_password"   xdotool -
fi

Review: Due Diligence, by David Roodman

Publisher:	Center for Global Development
Copyright:	2012
ISBN:	1-933286-48-2
Format:	Trade paperback
Pages:	335

Due Diligence: An Impertinent Inquiry into Microfinance is a detailed analysis of the effects, philosophy, approaches, and merits of microfinance as an institution and as, increasingly, a charitable focus of the developed world. The author, David Roodman, was a senior fellow at the Center for Global Development at the time of writing this book, and is an expert in microfinance and economic development. This book starts as an overview and a history of the spectrum of microfinance institutions (something I found very valuable, since I knew very little about microfinance prior to Kiva's popularity), and then attempts a critical, data-driven analysis of whether, to what extent, and by which measures microfinance is successful. The most common aspect of microfinance, made popular and prominent by Kiva among others, is microcredit: small loans to people in developing countries. The underlying theory of microcredit is that lack of financial services handicaps prospective entrepreneurs and business owners in the third world, preventing them from growing businesses, funding expansion, and moving out of poverty. By extending relatively small amounts of credit to these people, or so the theory goes, they can better smooth out the uncertainties of day-to-day life and get the necessary capital to expand small local business. Microcredit is not the only type of microfinance, though, and Roodman's careful discussion of that point was one of the most informative parts of this book for me. It can also come in the form of microsavings tiny bank accounts or small-scale savings plans or microinsurance. Roodman makes a very interesting argument that these three forms of microfinance form two opposing continuums. Microcredit is the easiest to provide and microinsurance is the hardest, for many reasons he discusses including some that were surprising to me, but microinsurance is arguably the most helpful and beneficial to the individual poor and microcredit is the least. The opening history and survey does an excellent job showing the range of techniques and approaches used in microfinance, and showing the challenges of providing it. I had some vague understanding of the logistical challenges in serving areas far away from traditional infrastructure. I had much less understanding of the fascinating array of techniques in use, both inside and outside what's become the microfinance industry. Some of these techniques are brilliant examples of human economic creativity and skill at balancing incentives with risk protection. There are a much wider variety of approaches and instruments available than the individual or group loans that one typically sees on a site like Kiva, all with different trade-offs in group size, flexibility, rigidity, risk, and complexity. This book is well worth reading just to get a feel for the huge array of financial arrangements possible outside of the traditional banking structures that most readers of this review are used to. Another question Roodman answers thoroughly is why microfinance is so focused on microcredit. My vague unease with that was strengthened by reading David Graeber's Debt, which among many other things makes clear some of the social perils and power imbalances in lending. Due Diligence both crystallized that discomfort and explained why alternatives are difficult. Both microsavings and microinsurance necessarily involve considerably more regulation (which has both advantages and complexity), since they involve taking and safeguarding people's money and promising service in the future. Lenders require less trust; lenders instead extend trust and assume that risk themselves, and are in a position to do so. Microinsurance is also harder to explain and harder to target, although it is potentially the most helpful financial instrument when well-targeted. And microcredit can absorb huge influxes of capital from the outside, lending it out in a region, while both microsavings and microinsurance are necessarily built on the money already in the local economy and are inherently more resistant to external involvement. (I'm of the opinion this is a significant feature, but it makes it far harder for them to catch on as a charitable trend.) The heart of the book is a hard look at whether microfinance, and particularly microcredit, works. Roodman attempts this analysis for three different definitions of working: lifting people out of poverty (the most commonly claimed success), giving people more freedom and control over their lives even if their poverty level does not change in absolute terms, and developing the local economy. Sadly for charities like Kiva, microcredit does surprisingly poorly on the first two metrics. There is still little clear data, and the degree to which data from one region is applicable to a different region is highly debatable, but what evidence we have does not support the theory that microcredit lifts people out of poverty. In fact, the more intense the microcredit, the more likely it appears to be that credit pathologies common in the developed world, such as taking out loans from one organization to pay off loans from another, spirals of debt that is unlikely to ever be repaid, and aggressive debt collection methods, turn up in microcredit as well. The vision of the entrepreneur who succeeds through new-found access to capital is largely a myth. Indeed, the current packaging and presentation of loans to distant charities in developed countries means that even the supposed purpose of the loans is dubious. Loans are almost always presented as being for some sort of business activity, since that's what external charities want to fund, but money is fungible and the funds are more often used for all the things people normally need to use funds for: weddings, funerals, food for the family in hard times, paying off other loans to relatives, and other daily expenses. On the empowerment front, microcredit fairs little better, and here I particularly appreciated Roodman's clear-eyed and honest portrayal of common microcredit practices and their benefits for the creditors. For example, microcredit makes much of loaning to women, and presents this as a story of female empowerment. Roodman argues that there is some reality behind that, but it's also clear that microcredit organizations loan to women because women are more likely to repay not due to any inherent gender trait, but because women are easier to intimidate and shame into repaying. Similarly, the much-vaunted group loans, usually presented as a way for the community to support each other and teach each other financial skills, are most common in the poorest regions because they represent an outsourcing of costs. The main risk to the lender is that poor people have no such thing as credit histories, and detailed investigations of someone's trustworthiness is expensive. Groups are jointly liable and therefore will police themselves and check each other's reliability at no cost to the lender. Groups will also use intimidation tactics and even violence against members who don't or can't repay their share, without the lender having to get involved or have any responsibility for those tactics. Roodman takes a philosophical tone on this topic, noting several times that services for the very poor are generally of low quality and finance is no exception. I'm less inclined to be philosophical; after reading this book, I find it very hard to support group loans. This leaves economic development as the most compelling argument left for microcredit. This is weak tea for people like myself who wanted to believe in the transformative power of microcredit, but Roodman does a solid job explaining why it's still important. There is a great deal to be said for the perspective that only industrialization actually lifts people out of poverty on any substantial scale, and therefore the most useful type of aid is aid that somehow contributes towards industrialization. Building a native financial industry could arguably be such a step. And there seems to be some real merit and lasting effect to having a richer and more capable set of local financial institutions. However, here, it's not at all clear that external money helps. In fact, there's quite a bit of evidence that external money hurts, since it pushes microfinance institutions to find ways of using that money and pleasing external donors instead of building their infrastructure and capabilities as financial institutions. The earlier institutions, such as the Grameen Bank, seem to have done a better job at being local institutions woven into the local economy than have the later organizations that are largely supported by western donors. Roodman makes a good case for the usefulness of microfinance as a part of economic development, but it comes with a strong argument against too much external funding, and particularly against the practice of developed world donors funding specific loans. I came away from this book feeling like I had a much better understanding of the core problems and techniques of financial services for the poor, and with a strong desire to see more microsavings than microcredit. The two are closer in nature than I had expected, and Roodman's analysis of the similarities was fascinating, but microsavings seems less vulnerable to some of the credit pathologies. There is also some statistical evidence that microsavings does provide some modest reductions in poverty, while the evidence for microcredit is much less compelling. Sadly, from the perspective of a resident of the developed world such as myself who would very much like to help, neither microsavings nor effective microcredit seems likely to benefit from my contributions, and particularly not in the form of a site like Kiva. The end of this book is a long appendix that reprints multiple blog posts on related topics, including additional discussion of the problems with the Kiva model. Effectively, Kiva is a way for people like myself to subsidize microcredit organizations. It's not at all clear that subsidies are needed, and there's some reason to believe that they encourage negative and destructive behavior. The way they are marketed involves a certain amount of lying, or at least distortion, on the part of multiple actors in the microcredit picture. And they're a distraction from microsavings, and from microcredit based on loaning out savings from within the same local economy, both of which seem to have considerably more positive properties. Due Diligence is a book with a somewhat narrow target audience. It will appeal primarily to people with an interest in economics, particularly development economics, or who are evaluating microfinance charities or analyzing their support of groups like Kiva. But within that context, this is an excellent book, and I recommend it to your attention. Roodman is clear, thorough, and fair within my ability to measure that, and while no one book can be the final word on a topic, he adds considerable data and thoughtful analysis. If you are a supporter of Kiva, like I was, I fear you'll find this book rather discouraging. But it's better to have the information than not, and I found it a good reminder of the inherent drawbacks of loans and debt. There is, sadly, nothing magical about microcredit that removes those problems. Rating: 9 out of 10

I am struck by the fragmentation in communication mechanisms. Let's look at how I have communicated with my friends in the past few days:

• Phone call
  Tried and tested, though I tend to avoid them. I've made some deliberate calls to sort out immediate plans, and at least one accidental call caused by user error which resulted in talking to someone it was good to hear from.
• Text message
  Again, reasonably tried and tested. I miss the inability to use Google Voice when I'm in the UK; I'd much rather read and compose text messages from my web browser when I'm near a computer than type them on my phone, even if it does have a keyboard.
• Email
  One of my favourite methods of communication. Suitable for quick messages or longer screeds. I can throw links in and expect you to be able to click them. I can put lots of detail so that everything is covered easily. I can confuse you by quoting correctly. I guess while I do read email on my phone I'm less likely to reply there as I'm always a bit embarrassed how the clients cope with replies.
• IRC
  Like, I suspect, many readers of my blog posts, I'm still a daily user of IRC. There are friends I keep in touch with mostly via this method. It's great. It's like Twitter for old people and much better in many ways.
• Skype
  This started out as a work thing. It was the way in which the Belfast office communicated with the US, it become the way the Belfast office communicated with each other and when I moved on it was the way in which I kept in contact with a group of people I consider good friends. It's great for calls (I feel bad saying that, but it's an idea executed well across multiple platforms and any other VOIP stuff I've played with has been much more of a hassle), but the one to one and group chat functionality is pretty spot on as well. Also has the advantage that I can turn it off and mostly not end up with work queries.
• Google Hangouts
  I actually quite like these. They work on my phone, I can poke them from a web browser, I can dump more than just text into them. IRC is better in some ways, but I do like the additional flexibility I get from a Hangout. It doesn't play well with people who haven't drunk the Google koolaid, which is the main reason I haven't managed to convince the Skype group chat group to move it over here.
• Facebook messenger
  I hate this. On the face of it there's not a lot of difference between it and Hangouts, but the app wants more and more privileges, I'm less likely to be logged into Facebook (e.g. I avoid it at work, whereas there are good reasons I'd be logged into my Google account there, though less so since the demise of Reader) and I don't think it's as nicely implemented. However there are a few people who it's easiest to get hold of via this method. And there's a certain amount of mesmerisation by the floaty wee faces it invokes on my phone.

While some of these work better for me than others really what I'd like is to use fewer of them, and I can't see that happening any time soon. I don't want to have to run a handful of different messaging apps on my phone. I also don't want to be limited to only using my laptop or my phone for something - I'd much prefer to be able to pickup the phone, laptop or tablet depending on what I'm up to and have my full range of communication available. Some of these things can be aggregated together, but that will then lose some of the advantages. And I'm sure that even if I got rid of one or two of the above there'd be something to fill the gap along shortly (I have, for example, so far completely avoided WhatsApp).

I have begun to push some of the Emacs Lisp Packages I have been working on over the last years to GNU ELPA, the Emacs Lisp Package Archive. That means you can use "M-x list-packages RET" to install them in GNU Emacs 24.

Review: Face of the Enemy, by Sandra Barret

Series:	Terran-Novan #1
Publisher:	Digital Mindancer
Copyright:	2007
Printing:	2009
ISBN:	1-934452-36-X
Format:	Kindle
Pages:	216

Set in a future SF world of an alliance of breakaway human colonies and a smoldering war between the Terrans (who focus on technology and implants) and the Novans (who have embraced genetic engineering), Face of the Enemy is military SF with a side of lesbian romance. Or vice versa. It was mentioned in a Tor.com roundup of SFF lesbian romance, and since I'd had good luck with lesbian romance and was looking for more light SF, I picked it up and read it between other things. Flaws first for this review: Face of the Enemy is not going to impress anyone with its originality. Technology versus bioengineering is an old, old bit of world-building. Barret doesn't bring much new to it other than enhanced pheromones, which provoked a bit of an eye roll. One protagonist is from a military family and is passionate about joining the family tradition, particularly since her mother is frequently blamed for the loss of a major battle. The other protagonist is the beautiful daughter of a diplomat but is half-Novan and hiding it, since the bioengineered Novans are second-class citizens viewed with suspicion and repulsion by the Terrans. You can doubtless make some good guesses about where the rest of the story goes. It's also the sort of story in which the protagonists are always the people you want to know: talented, eager, better than other cadets, but usually modest and loyal friends. Obviously, in a romance I want to like the protagonists and root for them. But the complex friendships of military cadets at the top of their class is another story that I've read many times before. That said, while it might sound like you could write the rest of the story from the setup, I was surprised several times. Barret throws in some twists and behind-the-scenes maneuvering, the complications generated by the backgrounds of both protagonists don't always follow expected patterns, and I was impressed by the degree to which the story manages to avoid clear-cut villains. I don't think it fully engages with the underclass on which both sides have built their societies, but there's at least some movement in that direction. The opening had set my expectations low, but there's more to this world than it first appears. I thought Barret did a reasonably good job staying consistent with the backgrounds of her characters: they have some connections, and those are somewhat helpful, but they're still trainees and never get unrealistic amounts of real responsibility. And I did like these people and enjoyed reading about them. The romance itself has significant love-at-first-sight elements and lots of missed communication and unspoken uncertainty, which aren't my favorite plot elements. As you might imagine, the dark secret aspect of hidden genetic engineering angle is played to the hilt, with lots of failed communication and jumping to incorrect conclusions on both sides. It's the kind of story where people have to knock the heads of the protagonists together to get them to open up to each other, but at least that does happen, and is rewarding when it does. Overall, I wouldn't recommend this book. It has significant flaws, some paint-by-numbers world-building, and some romantic stupidity. It's a minor work. But it did satisfy the reason I picked it up: light and unchallenging reading when I wanted something quick, optimistic, and with a happy ending. And although the romance isn't very original, it has the constant plus of lesbian romance: a refreshing deficit of standard sexist stereotypes. Rating: 5 out of 10

type=AVC msg=audit(1403622580.061:96): avc: denied write for pid=1331 comm="mysqld_safe" name="/" dev="dm-0" ino=256 scontext=system_u:system_r:mysqld_safe_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir
type=SYSCALL msg=audit(1403622580.061:96): arch=c000003e syscall=269 success=yes exit=0 a0=ffffffffffffff9c a1=7f5e09bfe798 a2=2 a3=2 items=0 ppid=1109 pid=1331 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mysqld_safe" exe="/bin/dash" subj=system_u:system_r:mysqld_safe_t:s0 key=(null) For a long time (probably years) I ve been seeing messages like the above in the log from auditd (/var/log/audit/audit.log) when starting mysqld. I haven t fixed it because the amount of work exceeded the benefit, it s just a couple of lines logged at every system boot. But today I decided to fix it. The first step was to find out what was going on, I ran a test system in permissive mode and noticed that there were no attempts to create a file (that would have been easy to fix). Then I needed to discover which system call was triggering this. The syscall number is 269, the file linux/x86_64/syscallent.h in the strace source shows that 269 is the system call faccessat. faccessat(2) and access(2) are annoying cases, they do all the permission checks for access but don t involve doing the operation so when a program uses those system calls but for some reason doesn t perform the operation in question (in this case writing to the root directory) then we just get a log entry but nothing happening to examine. A quick look at the shell script didn t make the problem obvious, note that this is probably obvious to people who are more skilled at shell scripting than me but it s probably good for me to describe how to solve these problems every step of the way. So the next step was to use gdb. Here is the start of my gdb session: # gdb /bin/sh
[skipped]
Reading symbols from /bin/dash (no debugging symbols found) done.
(gdb) b faccessat
Breakpoint 1 at 0 3960
(gdb) r -x /usr/bin/mysqld_safe
[lots skipped]
+ test -r /usr/my.cnf
Breakpoint 1, 0x00007ffff7b0c7e0 in faccessat ()
from /lib/x86_64-linux-gnu/libc.so.6 After running gdb on /bin/sh (which is a symlink to /bin/dash) I used the b command to set a breakpoint on the function faccessat (which is a library call from glibc that calls the system call sys_faccessat()). A breakpoint means that program execution will stop when the function is called. I run the shell script with -x as the first parameter to instruct the shell to show me the shell commands that are run so I can match shell commands to system calls. The above output shows the first call to faccessat() which isn t interesting (it s testing for read access). I then ran the c command in gdb to continue execution and did so a few times until I found something interesting. + test -w / -o root = root
Breakpoint 1, 0x00007ffff7b0c7e0 in faccessat ()
from /lib/x86_64-linux-gnu/libc.so.6 Above is the interesting part of the gdb output. It shows that the offending shell command is test -w / . I filed Debian bug #752593 [1] with a patch to fix this problem. I also filed a wishlist bug against strace asking for an easier way to discover the name of a syscall [2].

• [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752593
• [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752595

Twenty years ago, I was sixteen and in high school. The school at the time, if memory serves right, was the "Kunsthumaniora voor muziek en woord van het gemeenschapsonderwijs" in Brussels (which translates approximately to "art high school for music and word of the communal educational branch"... that's not entirely right, but it's late and I'm too tired to look for a dictionary). I was taking drama classes there. No, I'm not making this up. Except maybe the sixteen bit I might be off by one or two years. Hey, I did a lot of things during high school. Stop looking at me like that. At one point in time during my stint in drama, a group of educational interns the sort of people who would be teaching some sort of stuff somewhere after their graduation cooperated with our school to come up with a whole day of classes around one subject. I'll never forget the title: "Can art rescue the democracy?" If that sounds pompous and silly, that's because it was. However, I was at art school, fer crying out loud, so I drank it up like it was cool-aid. Which it wasn't. It was worse. At the end of the day (literally, that is), the educational interns had booked some hot shot art person for a debate. I've since completely forgotten his name. He must've been not that hot shot after all, since I never even once read anything about him in the next few years. Of course I can't exclude the most recent decade, not remembering him and all, but whatever. I also don't remember whether he was a hot shot art critic, a hot shot artist, or just some random hot shot person who writes about art, but doesn't actually do it himself. Whatever. One of the main topics during the whole day was the point about how artsy people find it extremely difficult to define what art actually is. I mean, it's all they do all day, but they can't come up with a decent definition of the damn thing. During the afternoon break, just before the debate with this maybe-sortof-semi hot shot art person, I walk around the playground and think about the whole thing. And come up with some personal definition of art. My definition. As the time of the debate comes up, the hot shot art person sits in the front of the gym behind some table, and the whole school (literally) is sitting in chairs in the rest of the gym. Some questions are asked. Many of those are just shot down. At some point, I raise my finger when it's asked if anyone has further questions. I walk up to the microphone. I ask him: "Could we maybe define art as that thing that, though it might be easy to reproduce, in no case is easy to produce?" He sits (he never got up, really). He thinks. I stand, and wait. After a few seconds of this, he answers. He seems impressed. His reply is something along the lines of "that's not a perfect definition, but it's pretty good. There's a lot to be said for that, and I urge you to write about art when you grow older". I never followed his advice. I got a bit more interested in art, but quickly found out that art consists of one group of people who spend their time doing things other people find pretty, and another group of people who spend their time doing things that makes other people "think", whatever that is. They may not have a brain, they may be silly as hell, but they still want to "think". It's not for me, it's never been. Art, that is -- not the think bit. That is something I don't mind doing. Don't get me wrong. I still like art. I like going to museums from time to time; I like the performing arts. I mean, I play the flute. Not the piano, not the guitar, not the flipping drums, the flute. Which I like, for what it's worth. But if the intent is to make people think, there are better ways to do that. If I want to make people think, I'm not going to make some obscure object that may or may not have a message, in the hope that a millionaire with no better use for his money would buy it just to make his friends jealous, after which he's going to put it in a safe for a few years so he can sell it at a higher value. Without thinking about it. If I want to make people think, I'm not going to write a play or piece of music that's so obscure it will make people all confused, so they can fill their evening afterwards drinking cocktails at a reception, claiming it was all nice and thought-provoking, quoting little parts of it to people they've never met, just so they can make their social status look more than it actually is. Good thing I never finished drama school, I suppose. No, if I want to make people think, I'll try doing so where it actually matters. Like, say, in politics. Not that I have any political ambitions, mind you. But I think the answer to that question of twenty years ago should be a firm "no." Art cannot rescue democracy. Not if they don't have a lot of interesting things to say to anyone but themselves. Maybe the reverse is true, though; maybe democracy can rescue art. Not that I care much. Why is all this relevant today? A few days ago, as I was driving somewhere, there was some show on the radio relating to the current exploits of the Belgian national soccer team. There are a lot of them these days. Radio shows about that subject, that is not Belgian national soccer teams. I suppose having a lot of competition makes it hard to find a new angle to come up with, and still keep things interesting. I also suppose having a lot of stuff going on about that squad gets people annoyed if they're not the least bit interested. I suppose that could be a new angle. Presumably that radio host supposed the same, because he'd been looking for, and asking questions of, people who didn't like soccer and who weren't going to watch the match. Most of them said they weren't interested and added one or two words about what they were going to be doing instead. One of them said that "they" would be better off spending money on "art and culture", rather than on soccer. No, I don't know who "they" were, he didn't say. Never mind that, let me go on now. I don't know who this dude was; they the radio people didn't say. He sounded like someone between 50 and 65, and had a somewhat tenor-y voice. I suspect he had two kids, and a mercedes. Yes, I just made that up. The part about the kids. And the car. No, it doesn't matter. But it's still likely. He sounded like that sort of guy. Whoever this dude was, though, I'd like to just say one thing: Dude, you're an idiot. There's a time and a place for everything. The time and place for art is "everywhen", and "in any random art gallery, opera house, or theatre, out of the public eye". Not because the rest of us doesn't want to deal with art, but because artsy people like it that way. They like to feel all pompous and important, and therefore use difficult words. Words that nobody except those along with them in their ivory tower like to use. Words that don't actually mean anything. But in doing so, they make this Art thing uninteresting to look at for people who don't care about their pompous and silly words. And strengthen the walls of their ivory tower. Only to complain later on that nobody ever shows up at art galleries, and that the really good ones keep going out of business. The time and place for the world championship soccer is "once every four years", and "everywhere". Not because soccer people want to annoy you although, yes, I'll grant you that the KBVB has gone a little overboard with the merchandising this time around but rather because it's so simple. You kick the ball, and you hit the goal. There, done. Everyone can do it. Yes, true, there are some pompous people talking about it on TV, too. And yes, true, some people are better at it than others. But nobody claims you can't do soccer unless you're part of the "in" club. There are plenty of people who claim you can't do art unless you are. And if everyone can do it, then everyone can understand it. If you can understand it, it's easier to enjoy it. This is why so few people enjoy cricket or baseball outside of the few countries where it's popular. That's also why so few people enjoy art: because you make it so difficult. And people just don't care. They want to be entertained. I'm not saying that soccer is the best sport in the world, or that watching it is the most entertaining thing one can do. It isn't. In fact, beyond the national team, I'm not really following it all that well myself. If through some weird spacial anomaly the world championship would suddenly cease to exist and I would be the only person alive remembering it, I don't think I'd spend a lot of time trying to get it back. But don't compare it to art. Because, well, in the grand scheme of things, neither of those two really matters all that much. That is all.

This post is partly introspection, and partly advertising. Skip if it either annoys you. Back in February I was thinking about what to do with myself. I had two main options "Get a job", and "Start a service". Because I didn't have any ideas that seemed terribly interesting I asked people what they would pay for. There were several replies, largely based "infrastructure hosting" (which was pretty much 50/50 split between "DNS hosting", and project hosting with something like trac, redmine, or similar). At the time DNS seemed hard, and later I discovered there were already at least two well-regarded people doing DNS things, with revision control. So I shelved the idea, after reaching out to both companies to no avail. (This later lead to drama, but we'll pretend it didn't.) Ultimately I sought and acquired gainful employment. Then, during the course of my gainful employment I was exposed to Amazons Route53 service. It looked like I was going to be doing many things with this, so I wanted to understand it more thoroughly than I did. That lead to the creation of a Dynamic-DNS service - which seemed to be about the simplest thing you could do with the ability to programatically add/edit/delete DNS records via an API. As this was a random hack put together over the course of a couple of nights I didn't really expect it to be any more popular than anything else I'd deployed, and with the sudden influx of users I wanted to see if I could charge people. Ultimately many people pretended they'd pay, but nobody actually committed. So on that basis I released the source code and decided to ignore the two main missing features - lack of MX records, and lack of sub-sub-domains. (Isn't it amazing how people who claim they want "open source" so frequently mean they want something with zero cost, they can run, and never modify and contribute toward?) The experience of doing that though, and the reminder of the popularity of the original idea made me think that I could do a useful job with Git + DNS combined. That lead to DNS-API - GitHub based DNS hosting. It is early days, but it looks like I have a few users, and if I can get more then I'll be happy. So if you want to to store your DNS records in a (public) GitHub repository, and get them hosted on geographically diverse anycasted servers .. well you know where to go: Github-based DNS hosting.

I have moved to a new OpenPGP key. There are many tutorials and blog posts on GnuPG key generation around, but none of them matched exactly the setup I wanted to have. So I wrote down the steps I took, to remember them if I need to in the future. Briefly my requirements were as follows:

• The new master GnuPG key is on an USB stick.
• The USB stick is only ever used on an offline computer.
• There are subkeys stored on a YubiKey NEO smartcard for daily use.
• I want to generate the subkeys using GnuPG so I have a backup.
• Some non-default hash/cipher preferences encoded into the public key.

After writing down the notes below, I posted about how to create a small JPEG image to embed in my OpenPGP key. I was planning to go live with the first key I generated, however as was gently pointed out to me, the JPEG image I generated was not optimal (too low quality and not sufficiently compressed). I have decided to retake the photo so I have a color image as a basis for size optimization. I don t want to postpone using the new key though, so I stepped through all of these steps again (except adding the photo) to get a new key. This is why the notes below are for a key 1C5C4717 that is now revoked. My new real key is 54265E8C. I will add the photo to my 54265E8C key once I have a JPEG file that I m happy with. Offline machine The offline machine setup I use is a Live CD on a machine that is physically well protected. I m using the Debian Live CD version 7.5.0 GNOME Desktop. The password for the auto-logged in user is live which you need if the screen-saver kicks in. Configure the keyboard layout if you need to. Insert an USB memory stick. I m using a VFAT filesystem to keep things simple; and for this writeup it happened to be mounted as /media/FA21-BEC7 so you will have to replace that path with something that points to your USB stick. Open a terminal since the rest of this writeup will be done from a terminal window. GnuPG configuration Set your GnuPG home directory to point at the USB memory device. You will need to do this in every terminal windows you open that you want to use GnuPG in.

user@debian:~$ export GNUPGHOME=/media/FA21-BEC7/gnupghome
user@debian:~$ mkdir $GNUPGHOME
user@debian:~$ 

The GnuPG defaults (as of version 1.4.16) to rank SHA1 higher than SHA384, SHA512, and SHA224 in the default hash preference list. To be precise, the default hash preference order is SHA256, SHA1, SHA384, SHA512, SHA224. I consider SHA1 broken so I don t advertise it all, although I believe that will not prevent some implementations of using SHA1 anyway since it is the mandatory to implement hash algorithm. Regarding symmetric ciphers, the default order is AES256, AES192, AES128, CAST5, 3DES. I don t like ciphers with 64-bit block lengths, so I don t advertise them but similarily, I believe this will not prevent some implementations of using CAST5 or 3DES anyway. I also advertise support for Twofish and Camellia in case someone wants to use them, they are 128-bit block length and relatively modern ciphers after all. The default-preference-list keyword is used to override the default settings, which will be recorded into any newly generated keys. GnuPG self-sign keys with SHA1 by default, and I prefer to use a member of the SHA2 family, hence the cert-digest-algo keyword. Further down below we will use the GnuPG Agent to talk to the smartcard, so configure GnuPG to use it with the use-agent keyword. GnuPG prints ugly warning messages about locking (gpg: DBG: locking for /media/FA21-BEC7/gnupghome/secring.gpg.lock' done via O_EXCL), presumably because of the VFAT filesystem, so I use lock-never to silence that.

user@debian:~$ cat > $GNUPGHOME/gpg.conf
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAMELLIA256 CAMELLIA192 CAMELLIA128 TWOFISH
cert-digest-algo SHA512
use-agent
lock-never
user@debian:~$ 

Generate master key Below I will use a 3744 bit RSA key, where the key size is selected based on the assumption that people will focus efforts to crack RSA keys on the usual power-of-two key sizes. I have chosen to not generate an encryption key, since I will use subkeys on a smartcard. With my old B565716F key I noticed that sometimes people will encrypt to my main encryption key even though I have encryption subkeys. Presumably this happens due to implementation flaws or user configuration mistakes. It could happen intentionally if someone had a public key from me with an expired subkeys but not expired main keys. This could be a reason to use the same expiration day for all your keys. Still, I chose to not generate an encryption key at all at this point. For additional protection, I m using a passphrase on the key.

user@debian:~$ gpg --gen-key
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: keyring  /media/FA21-BEC7/gnupghome/secring.gpg' created
gpg: keyring  /media/FA21-BEC7/gnupghome/pubring.gpg' created
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 3744
Requested keysize is 3744 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 100
Key expires at Fri 26 Sep 2014 10:50:22 PM UTC
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) "
Real name: Simon Josefsson
Email address: simon@josefsson.org
Comment: 
You selected this USER-ID:
    "Simon Josefsson "
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
...
gpg: /media/FA21-BEC7/gnupghome/trustdb.gpg: trustdb created
gpg: key 1C5C4717 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2014-09-26
pub   3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
      Key fingerprint = EF0A 1996 7B3B 4BAD 9D5C  A97F 1A44 08DD 1C5C 4717
uid                  Simon Josefsson 
Note that this key cannot be used for encryption.  You may want to use
the command "--edit-key" to generate a subkey for this purpose.
user@debian:~$ 

Add photo I m in the process of creating a better JPEG photo, so I skipped this step for my new key. However the notes here are correct anyway.

user@debian:~$ gpg --edit-key 1C5C4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
[ultimate] (1). Simon Josefsson 
gpg> addphoto
Pick an image to use for your photo ID.  The image must be a JPEG file.
Remember that the image is stored within your public key.  If you use a
very large picture, your key will become very large as well!
Keeping the image close to 240x288 is a good size to use.
Enter JPEG filename for photo ID: /media/FA21-BEC7/simon-gpg.jpg
Is this photo correct (y/N/q)? y
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
[ultimate] (1). Simon Josefsson 
[ unknown] (2)  [jpeg image of size 6048]
gpg> save
user@debian:~$ 

Add another identity Most people have multiple email addresses, and this needs to be reflected in the GnuPG key. Use the primary command to specify your main User ID.

user@debian:~$ gpg --edit-key 1C5C4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
[ultimate] (1). Simon Josefsson 
[ultimate] (2)  [jpeg image of size 6048]
gpg> adduid
Real name: Simon Josefsson
Email address: simon@yubico.com
Comment: 
You selected this USER-ID:
    "Simon Josefsson "
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
[ultimate] (1)  Simon Josefsson 
[ultimate] (2)  [jpeg image of size 6048]
[ unknown] (3). Simon Josefsson 
gpg> uid 1
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
[ultimate] (1)* Simon Josefsson 
[ultimate] (2)  [jpeg image of size 6048]
[ unknown] (3). Simon Josefsson 
gpg> primary
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
[ultimate] (1)* Simon Josefsson 
[ultimate] (2)  [jpeg image of size 6048]
[ unknown] (3)  Simon Josefsson 
gpg> save
user@debian:~$ 

Create a revocation certificate It is good practice to generate a revocation certificate in case you lose your key. Store this in a safe place, possibly printed out on paper.

user@debian:~$ gpg --output $GNUPGHOME/../revocation-certificate.txt --gen-revoke 1C5C4717
sec  3744R/1C5C4717 2014-06-18 Simon Josefsson 
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> Created during key creation, emergency use only.
> 
Reason for revocation: Key has been compromised
Created during key creation, emergency use only.
Is this okay? (y/N) y
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18
ASCII armored output forced.
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!
user@debian:~$ 

Make a backup of the master key To have an easy way to move back and forward in time in GnuPG, I both export the key to a stable data format and keep a backup of the actual GnuPG home directory.

user@debian:~$ gpg -a --export-secret-keys 1C5C4717 > $GNUPGHOME/../masterkey.txt
user@debian:~$ cp -a $GNUPGHOME $GNUPGHOME-backup-masterkey
user@debian:~$ 

Create subkeys Now I will generate three keys that will go onto the smartcard. I have chosen to generate these using GnuPG and then move the keys onto the smartcards, instead of generating the keys directly on the card. The difference is that with this approach, I get a backup of the keys and can import them to another key in the future if I need to. Each key has its own purpose: Signature, Encryption, and Authentication. Smartcards typically have limitation on key sizes, so I select 2048 as a widely supported size. Expert mode is required to generate authentication subkeys.

user@debian:~$ gpg --expert --edit-key 1C5C4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
[ultimate] (1). Simon Josefsson 
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson 
gpg> addkey
Key is protected.
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 100
Key expires at Fri 26 Sep 2014 11:03:16 PM UTC
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
..+++++
....+++++
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S   
[ultimate] (1). Simon Josefsson 
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson 
gpg> addkey
Key is protected.
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
Your selection? 6
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 100
Key expires at Fri 26 Sep 2014 11:03:31 PM UTC
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
......+++++
Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 7 more bytes)
.+++++
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S   
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E   
[ultimate] (1). Simon Josefsson 
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson 
gpg> addkey
Key is protected.
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
Your selection? 8
Possible actions for a RSA key: Sign Encrypt Authenticate 
Current allowed actions: Sign Encrypt 
   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished
Your selection? s
Possible actions for a RSA key: Sign Encrypt Authenticate 
Current allowed actions: Encrypt 
   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished
Your selection? e
Possible actions for a RSA key: Sign Encrypt Authenticate 
Current allowed actions: 
   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished
Your selection? a
Possible actions for a RSA key: Sign Encrypt Authenticate 
Current allowed actions: Authenticate 
   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished
Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 100
Key expires at Fri 26 Sep 2014 11:03:59 PM UTC
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++
Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 56 more bytes)
+++++
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S   
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E   
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A   
[ultimate] (1). Simon Josefsson 
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson 
gpg> save
user@debian:~$ 

Export subkeys for backup This is a good time to save a restore point for your key. Note in the output of --list-secret-keys the keywords sec and ssb which means the main key and the subkeys are available. If the secret keyring contained only stubs, it would be sec> and sec#.

user@debian:~$ gpg --list-keys
/media/FA21-BEC7/gnupghome/pubring.gpg
--------------------------------------
pub   3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
uid                  Simon Josefsson 
uid                  [jpeg image of size 6048]
uid                  Simon Josefsson 
sub   2048R/72D5245B 2014-06-18 [expires: 2014-09-26]
sub   2048R/A11F46D2 2014-06-18 [expires: 2014-09-26]
sub   2048R/D6987A02 2014-06-18 [expires: 2014-09-26]
user@debian:~$ gpg --list-secret-keys
/media/FA21-BEC7/gnupghome/secring.gpg
--------------------------------------
sec   3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
uid                  Simon Josefsson 
uid                  [jpeg image of size 6048]
uid                  Simon Josefsson 
ssb   2048R/72D5245B 2014-06-18
ssb   2048R/A11F46D2 2014-06-18
ssb   2048R/D6987A02 2014-06-18
user@debian:~$ gpg -a --export-secret-keys 1C5C4717 > $GNUPGHOME/../mastersubkeys.txt
user@debian:~$ gpg -a --export-secret-subkeys 1C5C4717 > $GNUPGHOME/../subkeys.txt
user@debian:~$ cp -a $GNUPGHOME $GNUPGHOME-backup-mastersubkeys
user@debian:~$ 

Configure machine for smartcards The YubiKey NEO requires that RSA keys are imported with some additional parameters, used for CRT speedups. This was fixed in GnuPG 2.0.22. Unfortunately, it is not fixed in GnuPG 1.x. However, GnuPG 1.x can use gpg-agent and scdaemon from GnuPG to communicate with the smartcard. So let s work around the limitation in GnuPG 1.x by installing parts from GnuPG 2.x and use those. You will need to install the following packages: gnupg-agent, libpth20, pinentry-curses, libccid, pcscd, scdaemon, libksba8. Make sure that scdaemon is version 2.0.22 or later (get it from backports). I downloaded these packages and put them on the USB stick. Unfortunately, libccid in Debian is a bit outdated, and does not contain the USB device vendor/product ID in /etc/libccid_Info.plist. You will need to manually add this, and restart pcscd. user@debian:~$ sudo gedit /etc/libccid_Info.plist
user@debian:~$ sudo service pcscd restart Start gnupg-agent and setup the environment variable for this session:

user@debian:~$ gpg-agent --daemon
gpg-agent[22556]: directory  /media/FA21-BEC7/gnupghome/private-keys-v1.d' created
GPG_AGENT_INFO=/tmp/gpg-wGji5C/S.gpg-agent:22557:1; export GPG_AGENT_INFO;
gpg-agent[22557]: gpg-agent (GnuPG) 2.0.22 started
user@debian:~$ GPG_AGENT_INFO=/tmp/gpg-wGji5C/S.gpg-agent:22557:1; export GPG_AGENT_INFO;
user@debian:~$ 

Prepare YubiKey NEO Make sure you have a recent firmware version, 3.1.8 or later; use lsusb -v to find out. Make sure the device is in OTP/CCID or CCID mode, use ykpersonalize -m from the YubiKey Personalization project to switch. Make sure you have the OpenPGP applet loaded properly, otherwise see the YubiKey NEO OpenPGP applet project on installing it. You may want to set a proper Application ID, see herlo s ssh-gpg-smartcard-config github repository for some hints. Configure OpenPGP applet This also changes the PIN and Admin codes.

user@debian:~$ gpg --card-edit
Application ID ...: D2760001240102000060000000420000
Version ..........: 2.0
Manufacturer .....: unknown
Serial number ....: 00000042
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]
gpg/card> admin
Admin commands are allowed
gpg/card> passwd
gpg: OpenPGP card no. D2760001240102000060000000420000 detected
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? 3
PIN changed.
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? 1
PIN changed.
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? q
gpg/card> name
Cardholder's surname: Josefsson
Cardholder's given name: Simon
gpg/card> lang
Language preferences: sv
gpg/card> url
URL to retrieve public key: https://josefsson.org/1c5c4717.txt
gpg/card> sex
Sex ((M)ale, (F)emale or space): m
gpg/card> login
Login data (account name): jas
gpg/card> 
Application ID ...: D2760001240102000060000000420000
Version ..........: 2.0
Manufacturer .....: unknown
Serial number ....: 00000042
Name of cardholder: Simon Josefsson
Language prefs ...: sv
Sex ..............: male
URL of public key : https://josefsson.org/1c5c4717.txt
Login data .......: jas
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]
gpg/card> quit
user@debian:~$ 

Move subkeys to YubiKey NEO Moving subkeys to a NEO is a destructive operation, so make sure you took backups of the subkeys as above. After this step, your GnuPG keyring will contain stubs for the subkeys.

user@debian:~$ gpg --edit-key 1C5C4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S   
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E   
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A   
[ultimate] (1). Simon Josefsson 
[ultimate] (2)  [jpeg image of size 6048]
[ultimate] (3)  Simon Josefsson 
gpg> toggle
sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never     
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never     
ssb  2048R/D6987A02  created: 2014-06-18  expires: never     
(1)  Simon Josefsson 
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson 
gpg> key 1
sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb* 2048R/72D5245B  created: 2014-06-18  expires: never     
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never     
ssb  2048R/D6987A02  created: 2014-06-18  expires: never     
(1)  Simon Josefsson 
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson 
gpg> keytocard
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 1
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
2048-bit RSA key, ID 72D5245B, created 2014-06-18
sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb* 2048R/72D5245B  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never     
ssb  2048R/D6987A02  created: 2014-06-18  expires: never     
(1)  Simon Josefsson 
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson 
gpg> key 1
sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never     
ssb  2048R/D6987A02  created: 2014-06-18  expires: never     
(1)  Simon Josefsson 
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson 
gpg> key 2
sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb* 2048R/A11F46D2  created: 2014-06-18  expires: never     
ssb  2048R/D6987A02  created: 2014-06-18  expires: never     
(1)  Simon Josefsson 
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson 
gpg> keytocard
Signature key ....: EF34 D1F7 95C0 3392 E52A  54FE DFF1 6372 72D5 245B
Encryption key....: [none]
Authentication key: [none]
Please select where to store the key:
   (2) Encryption key
Your selection? 2
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
2048-bit RSA key, ID A11F46D2, created 2014-06-18
sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb* 2048R/A11F46D2  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb  2048R/D6987A02  created: 2014-06-18  expires: never     
(1)  Simon Josefsson 
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson 
gpg> key 2
sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb  2048R/D6987A02  created: 2014-06-18  expires: never     
(1)  Simon Josefsson 
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson 
gpg> key 3
sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb* 2048R/D6987A02  created: 2014-06-18  expires: never     
(1)  Simon Josefsson 
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson 
gpg> keytocard
Signature key ....: EF34 D1F7 95C0 3392 E52A  54FE DFF1 6372 72D5 245B
Encryption key....: E24D 5135 C2FC 905C 8995  ACD8 EC96 9E77 A11F 46D2
Authentication key: [none]
Please select where to store the key:
   (3) Authentication key
Your selection? 3
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
2048-bit RSA key, ID D6987A02, created 2014-06-18
sec  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb  2048R/72D5245B  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb  2048R/A11F46D2  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
ssb* 2048R/D6987A02  created: 2014-06-18  expires: never     
                     card-no: 0060 00000042
(1)  Simon Josefsson 
(2)  [jpeg image of size 6048]
(3)  Simon Josefsson 
gpg> save
user@debian:~$ 

Take another backup Can you tell yet that I like having backup options? Note that the subkeys are now marked ssb> indicating they are stubs for a smartcard key.

user@debian:~$ gpg --list-secret-keys
/media/FA21-BEC7/gnupghome/secring.gpg
--------------------------------------
sec   3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
uid                  Simon Josefsson 
uid                  [jpeg image of size 6048]
uid                  Simon Josefsson 
ssb>  2048R/72D5245B 2014-06-18
ssb>  2048R/A11F46D2 2014-06-18
ssb>  2048R/D6987A02 2014-06-18
user@debian:~$ gpg -a --export-secret-keys 1C5C4717 > $GNUPGHOME/../masterstubs.txt
user@debian:~$ gpg -a --export-secret-subkeys 1C5C4717 > $GNUPGHOME/../subkeysstubs.txt
user@debian:~$ gpg -a --export 1C5C4717 > $GNUPGHOME/../publickey.txt
user@debian:~$ cp -a $GNUPGHOME $GNUPGHOME-backup-masterstubs

Transfer to daily machine Copy publickey.txt to your day-to-day laptop and import it.

jas@latte:~$ gpg --import < publickey.txt 
gpg: key 1C5C4717: public key "Simon Josefsson " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
jas@latte:~$ 

Insert the YubiKey NEO and generate secret key stubs:

jas@latte:~$ gpg --card-status
Application ID ...: D2760001240102000060000000420000
Version ..........: 2.0
Manufacturer .....: unknown
Serial number ....: 00000042
Name of cardholder: Simon Josefsson
Language prefs ...: sv
Sex ..............: male
URL of public key : https://josefsson.org/1c5c4717.txt
Login data .......: jas
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 0 0 0
PIN retry counter : 0 0 0
Signature counter : 0
Signature key ....: EF34 D1F7 95C0 3392 E52A  54FE DFF1 6372 72D5 245B
      created ....: 2014-06-18 23:03:16
Encryption key....: E24D 5135 C2FC 905C 8995  ACD8 EC96 9E77 A11F 46D2
      created ....: 2014-06-18 23:03:31
Authentication key: 2768 2EF9 415C 19FC F0CC  9CA5 DA81 BA39 D698 7A02
      created ....: 2014-06-18 23:03:59
General key info..: pub  2048R/72D5245B 2014-06-18 Simon Josefsson 
sec#  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26
ssb>  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26
                      card-no: 0060 00000042
ssb>  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26
                      card-no: 0060 00000042
ssb>  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26
                      card-no: 0060 00000042
jas@latte:~$ 

Now you should have a offline master key with subkey stubs. Note that the master key is not available (sec#) and the subkeys are stubs for smartcard keys (ssb>).

jas@latte:~$ gpg --list-secret-keys 1c5c4717
sec#  3744R/1C5C4717 2014-06-18 [expires: 2014-09-26]
uid                  Simon Josefsson 
uid                  [jpeg image of size 6048]
uid                  Simon Josefsson 
ssb>  2048R/72D5245B 2014-06-18 [expires: 2014-09-26]
ssb>  2048R/A11F46D2 2014-06-18 [expires: 2014-09-26]
ssb>  2048R/D6987A02 2014-06-18 [expires: 2014-09-26]
jas@latte:~$ 

Mark the key as ultimately trusted.

jas@latte:~$ gpg --edit-key 1c5c4717
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: unknown       validity: unknown
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S   
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E   
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A   
[ unknown] (1). Simon Josefsson 
[ unknown] (2)  [jpeg image of size 6048]
[ unknown] (3)  Simon Josefsson 
gpg> trust
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: unknown       validity: unknown
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S   
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E   
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A   
[ unknown] (1). Simon Josefsson 
[ unknown] (2)  [jpeg image of size 6048]
[ unknown] (3)  Simon Josefsson 
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
pub  3744R/1C5C4717  created: 2014-06-18  expires: 2014-09-26  usage: SC  
                     trust: ultimate      validity: unknown
sub  2048R/72D5245B  created: 2014-06-18  expires: 2014-09-26  usage: S   
sub  2048R/A11F46D2  created: 2014-06-18  expires: 2014-09-26  usage: E   
sub  2048R/D6987A02  created: 2014-06-18  expires: 2014-09-26  usage: A   
[ unknown] (1). Simon Josefsson 
[ unknown] (2)  [jpeg image of size 6048]
[ unknown] (3)  Simon Josefsson 
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> quit
jas@latte:~$ 

Signing keys This needs to be done using your master key, since it is your certification key that will be used. So boot the Live CD and make the usual GnuPG configurations. Below I m signing my own old key (0xB565716F) so the output may look a bit confusing with me signing my own key, but there is really two different keys involved here. The same process apply if you want to sign someone else s key too. Before signing the key, you need to put the public key on a USB stick and move it to the secure machine. On your laptop:

jas@latte:~$ gpg -a --export b565716f > /media/KINGSTON/b565716f.txt
jas@latte:~$ 

On the disconnected machine:

user@debian:~$ gpg --import < /media/KINGSTON/b565716f.txt 
gpg: key B565716F: public key "Simon Josefsson " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2014-09-26
user@debian:~$ gpg --sign-key b565716f
pub  1280R/B565716F  created: 2002-05-05  expires: 2014-11-10  usage: SC  
                     trust: unknown       validity: unknown
sub  2048R/105E722E  created: 2012-03-13  expires: 2014-11-10  usage: S   
sub  2048R/728AB82C  created: 2012-03-13  expires: 2014-11-10  usage: E   
sub  2048R/9394F626  created: 2012-03-13  expires: 2014-11-10  usage: A   
sub  1280R/4D5D40AE  created: 2002-05-05  expires: 2014-11-10  usage: E   
sub  1024R/09CC4670  created: 2006-03-18  expired: 2011-05-23  usage: A   
sub  1024R/AABB1F7B  created: 2006-03-18  expired: 2011-05-23  usage: S   
sub  1024R/A14C401A  created: 2006-03-18  expired: 2011-05-23  usage: E   
[ unknown] (1). Simon Josefsson 
[ unknown] (2)  Simon Josefsson 
[ revoked] (3)  Simon Josefsson 
Really sign all user IDs? (y/N) y
User ID "Simon Josefsson " is revoked.  Unable to sign.
pub  1280R/B565716F  created: 2002-05-05  expires: 2014-11-10  usage: SC  
                     trust: unknown       validity: unknown
 Primary key fingerprint: 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
     Simon Josefsson 
     Simon Josefsson 
This key is due to expire on 2014-11-10.
Are you sure that you want to sign this key with your
key "Simon Josefsson " (1C5C4717)
Really sign? (y/N) y
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 1C5C4717, created 2014-06-18
user@debian:~$ 

Then export the newly signed key back to your laptop for further distribution.

user@debian:~$ gpg -a --export b565716f > /media/KINGSTON/signed-b565716f.txt
user@debian:~$ 

On your laptop, either email it encrypted to the other person, or upload it to keyservers directly depending on your preference. By emailing it encrypted to the other person, they need to prove posession of the key before receiving your signature. In my case, I m the other person, so I just import the signed key and then send the key:

jas@latte:~$ gpg --import < /media/KINGSTON/signed-b565716f.txt
jas@latte:~$ gpg --send-keys b565716f

Key transition Since I'm migrating from an key to a new, I sign my new key using my old key, and publish that signature on keyservers. This allows people to trust my new key more easily. To let the world know about your key transition, I created a key transition statement. The transition statement should be signed by both keys. I created a new temporary GnuPG home directory and imported both master keys, and clearsigned the file. Note that I used "54265e8c!" to make GnuPG use the master key for signing rather than a subkey, which it would normally do.

user@debian:~$ export GNUPGHOME=/tmp/kts
user@debian:~$ mkdir $GNUPGHOME
user@debian:~$ gpg --import b565716f.txt 
gpg: WARNING: unsafe permissions on homedir  /tmp/kts'
gpg: keyring  /tmp/kts/secring.gpg' created
gpg: keyring  /tmp/kts/pubring.gpg' created
gpg: key B565716F: secret key imported
gpg: /tmp/kts/trustdb.gpg: trustdb created
gpg: key B565716F: public key "Simon Josefsson " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
user@debian:~$ gpg --import /media/FA21-AE97/secret-master-subkeys.txt 
gpg: WARNING: unsafe permissions on homedir  /tmp/kts'
gpg: key 54265E8C: secret key imported
gpg: key 54265E8C: public key "Simon Josefsson " imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
user@debian:~$ cat key-transition-2014-06-22-unsigned.txt   gpg --clearsign --personal-digest-preferences "SHA512" --local-user b565716f --local-user 54265e8c! > key-transition-2014-06-22.txt 
gpg: WARNING: unsafe permissions on homedir  /tmp/kts'
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
3744-bit RSA key, ID 54265E8C, created 2014-06-22
                  
You need a passphrase to unlock the secret key for
user: "Simon Josefsson "
1280-bit RSA key, ID B565716F, created 2002-05-05
user@debian:~$    

My statement is available as https://josefsson.org/key-transition-2014-06-22.txt if you want to download the signed text file directly. Feel free to base your own document on it, as I based mine on earlier examples.

I used to read Slashdot, many many years ago. However, when they started to do more and more "Your rights online" articles, I gradually stopped to read them. Someone just sent me a link to a slashdot article: m.slashdot.org. If I try to open this with Lynx, I get the following error page:

It looks like your browser doesn't support JavaScript or it is disabled.
Please use the desktop site instead.

OK FaceBook^WSlashdot, all the geeks formerly employed by you have obviously left. And no, I am not going to read you anytime soon. BTW, the link to the "desktop site" goes here, which looses the reference to the particular story, if you notice. So your redirection site is totally useless. Thanks for nothing. Hush hush, to the ethernal internet graveyard where you belong.

I have created a new OpenPGP key 54265e8c and will be transitioning away from my old key. If you have signed my old key, I would appreciate signatures on my new key as well. I have created a transition statement that can be downloaded from https://josefsson.org/key-transition-2014-06-22.txt. Below is the signed statement.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
OpenPGP Key Transition Statement for Simon Josefsson
I have created a new OpenPGP key and will be transitioning away from
my old key.  The old key has not been compromised and will continue to
be valid for some time, but I prefer all future correspondence to be
encrypted to the new key, and will be making signatures with the new
key going forward.
I would like this new key to be re-integrated into the web of trust.
This message is signed by both keys to certify the transition.  My new
and old keys are signed by each other.  If you have signed my old key,
I would appreciate signatures on my new key as well, provided that
your signing policy permits that without re-authenticating me.
The old key, which I am transitioning away from, is:
pub   1280R/B565716F 2002-05-05
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
The new key, to which I am transitioning, is:
pub   3744R/54265E8C 2014-06-22
      Key fingerprint = 9AA9 BDB1 1BB1 B99A 2128  5A33 0664 A769 5426 5E8C
The entire key may be downloaded from: https://josefsson.org/54265e8c.txt
To fetch the full new key from a public key server using GnuPG, run:
  gpg --keyserver keys.gnupg.net --recv-key 54265e8c
If you already know my old key, you can now verify that the new key is
signed by the old one:
  gpg --check-sigs 54265e8c
If you are satisfied that you've got the right key, and the User IDs
match what you expect, I would appreciate it if you would sign my key:
  gpg --sign-key 54265e8c
You can upload your signatures to a public keyserver directly:
  gpg --keyserver keys.gnupg.net --send-key 54265e8c
Or email simon@josefsson.org (possibly encrypted) the output from:
  gpg --armor --export 54265e8c
If you'd like any further verification or have any questions about the
transition please contact me directly.
To verify the integrity of this statement:
  wget -q -O- https://josefsson.org/key-transition-2014-06-22.txt gpg --verify
/Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iLwEAQEKAAYFAlOnV+AACgkQ7aIelLVlcW89XgUAljJgYfReyR9/bU+Om6UHUttt
CAOgSRqdcQSQ2hT69vzuhb/bc8CslIQcBtGqTgxDFsxEFhbm5zKn+tSzy5MHNHqt
MsqHcZjlYuYVhMXDhka+cfyhtd9zIxjVE5vk8v+GqEGoh8DGYq0vPy3VfvcSz5Z3
MSUpSj8gN00jlU1z4nad3maEq0ApvsLr8EsLZmtxF5TNFvzJ8mmwY+gHBGHjVYkB
8AQBAQoABgUCU6dX4AAKCRAGZKdpVCZejD1eDp46XGL2puMp0le2OF75WIUW8xqf
TMiZeB99ruk3P/jvuLnGPP2J5o7SIKE50FkMEss0yvxi6jBlHk+cJeKWGXVjBpxU
0QHq063NU+kjbMYwDfi5ZxXqaKeYODJm8Xmfh3d7lRaWF5rUOosR8nC/OROSrhg4
TjlAbvbxpQsls/JPbbporK2gbAtMlzJPD8zC8z/dT+t0qjlce8fADugblVW3bACC
Kl53X4XpojzNd/U19tSXkIBdNY/GVJqci+iruiJ1WGARF9ocnIXVuNXsfyt7UGq4
UiM/AeDVzI76v1QnE8WpsmSXzi2zXe3VahUPhOU2nPDoL53ggiVsTY3TwilvQLfX
Av/74PIaEtCi1g23YeojQlpdYzcWfnE+tUyTSNwPIBzyzHvFAHNg1Pg0KKUALsD9
P7EjrMuz63z2276EBKX8++9GnQQNCNfdHSuX4WGrBx2YgmOOqRdllMKz6pVMZdJO
V+gXbCMx0D5G7v50oB58Mb5NOgIoOnh3IQhJ7LkLwmcdG39yCdpU+92XbAW73elV
kmM8i0wsj5kDUU2ys32Gj2HnsVpbnh3Fvm9fjFJRbbQL/FxNAjzNcHe4cF3g8hTb
YVJJlzhmHGvd7HvXysJJaa0=
=ZaqY
-----END PGP SIGNATURE-----

I just did some Debian package review in a somewhat unusual way, and I wanted to share that. I'm hoping other Debian developers (and other free software contributors) that need to review others' contributions can learn something from this, and that I can use this blog post as a way to find out if other people are doing something similar. It was pretty exciting! At the end of it, I joined #debian-mentors to talk about how my cool process. Someone summarized it very accurately:

<sney> it almost sounds like you're working to replace yourself with automation

Context about alpine in Debian (Skip to "Package review, with automation" if you're familiar with Debian.) I'm the maintainer of alpine in Debian. There are quite a few problems with the alpine package in Debian right now, the biggest of which are:

• We're one version behind -- 2.11 is the latest available, but 2.10 is the newest that we have in Debian.

• The packaging uses a decreasingly-popular packaging helper, cdbs, about which I happen to know less than the dh-style helper (aka dh7).

• There are lots of bugs filed, and I don't respond in a timely fashion.

This doesn't change my deep love for alpine -- I've had that for about half my life now, and so far, I don't see it going away. A month or so ago, I got a friendly private message from Unit193, saying he had converted the package to the dh style, and also packaged the newer version. They wanted to know if they should clean this up into something high-enough quality to land in Debian. (In Debian, we have a common situation where enthusiastic users update or create a new package, and aren't yet Debian Developers, so they don't have permission to upload that directly to the "Debian archive", which is the Debian equivalent of git master. Package "sponsorship" is how we handle that -- a Debian Developer reviews the package, makes sure it is of high quality, and uploads it to the Debian archive along with the Debian Developer's OpenPGP signature, so the archive processing tools know to trust it.) On Friday evening, I had a spare moment, so I sent a private message to Unit193 apologizing for not getting back to them in a reasonable amount of time. Having another person help maintain is a pretty exciting prospect, and I wanted to treat that enthusiasm with the respect it deserves, or at least apologize when I haven't. I was surprised to see a reply within a few minutes. At that point, I thought: I wasn't planning on doing any package review this weekend, but if they're online and I'm online... might as well!

Package review, with automation Unit193 and I popped into ##alpine on irc.freenode.net, and I started reading through their packaging changes, asking questions. As I asked questions, I wondered -- how will I know if they are going to fix the issues I'm raising? Luckily, Unit193 wanted to use git to track the packaging, and we settled on using git-buildpackage, a tool that was fairly new to both of us. I thought, I might as well have some executable documentation so I don't forget how to use it. ("Executable documentation" is Asheesh-speak for a shell script.) One thing I knew was that I'd have to test the package in a pbuilder, or other pristine build environment. But all I had on me at the moment was my work laptop, which didn't have one set up. Then I had a bright idea: I could use Travis-CI, a public continuous integration service, to check Unit193's packaging. If I had any concerns, I could add them to the shell script and then point at the build log and say, "This needs to be fixed." Then there would be great clarity about the problems. Some wonderful things about Travis-CI:

• They give you root access on an Ubuntu Precise (10.04) virtual machine.
• Their build hosts are well-connected to the Internet, which means fast downloads in e.g. pbuilder.
• They will let you run a build for up to 50 minutes, for free.
• Build just means "command" or "set of commands," so you can just write a shell script and they will run it.
• Travis-CI will watch a github.com repository, if you like. This means you can 'git commit --allow-empty' then 'git push' and ask it to re-run your script.

Since Unit193's packaging was in git (but not on github), I created a git repo containing the same contents, where I would experiment with fixes for packaging problems I found. It'd be up to Unit193 to fix the problems in the Alioth packaging. This way, I would be providing advice, and Unit193 would have an opportunity to ask questions, so it would be more like mentorship and less like me fixing things. We did a few rounds of feedback this way, and got the packaging to higher and higher quality. Every time Unit193 made a fix and pushed it, I would re-run the auto-build, and see if the problems I spotted had gone away. While the auto-build runs, I can focus on conversing with my mentee about problems or just generally chatting. Chatting is valuable community-building! It's extremely nice that I can do that while waiting on the build, knowing that I don't have to read it carefully -- I can just wait a few minutes, then see if it's done, and see if it's red or green. Having the mentee around while I'm reviewing it means that I can use the time I'm waiting on builds as fun free software social time. (Contrast this with asynchronous review, where, all alone, I would wait for a build to finish, then write up an email at the end of it all.) This kind of mentorship + chatting was spread out over Friday night, Saturday night, and Sunday morning. By the end of it, we had a superb package that I'm excited to sign and push into Debian when I'm next near my OpenPGP key.

Implementation details You can see the final shell script here:

• do.sh

And you can see the various builds here:

• builds

The shell script:

• Alternates between the Alioth packaging vs. my fork of it. (This way, I can test packaging changes/suggestions.)
• Disables ccache in pbuilder, due to a permissions problem with ccache/pbuilder/travis-ci, and I didn't need ccache anyway.
• Handles 'git dch' slightly wrong. I need to figure that out.
• Optionally passes --git-ignore-new to git-buildpackage, which was required initially, but should not be required by the time the package is ready. (This is an example of a thing I might forget to remark upon to my mentee.)
• Plays games with git branches so that git-buildpackage on Travis-CI can find the pristine-tar branch.
• Tries to use cdn.debian.net as its mirror, but on Saturday ran into problems with whicever mirror that is, so it falls back to mirror.mit.edu in case that fails.
• Contains a GPG homedir, and imports the Debian archive key, so that it can get past Ubuntu-Debian pbuilder trust issues.

I also had a local shell script that would run, effectively:

• git commit --allow-empty -m 'Trigger build'
• git push

This was needed since I was basically using Travis-CI as remote shell service -- moreover, the scripts Travis-CI runs are in a different repo (travis-debcheck) than the software I'm actually testing (collab-maint/alpine.git). Unit193 and I had a technical disagreement at one point, and I realized that rather than discuss it, I could just ask Travis-CI to test which one of us was right. At one point in the revisions, the binary package build failed to build on Precise Pangolin (the Ubuntu release that the Travis-CI worker is running), and Unit193 said that it was probably due to a problem with building on Ubuntu. So I added a configuration option to build just the source package in Ubuntu, keeping the binary package test-build within the Debian sid pbuilder, although I believed that there was actually a problem with the packaging. This way, I could modify the script so that I could demonstrate the problem could be reproduced in a sid pbuilder. Of course, by the time I got that far, Unit193 had figured out that it was indeed a packaging bug. I also created an option to SKIP_PBUILDER; initially, I wanted to get quick automated feedback on the quality of the source package without waiting for pbuilder to create the chroot and for the test build to happen. You might notice that the script is not very secure -- Niels Thykier already did! That's fine by me; it's only Travis-CI's machines that could be worsened by that insecurity, and really, they already gave me a root shell with no password. (This might sound dismissive of Travis-CI -- I don't mean it to be! I just mean that their security model already presumably involves throwing away the environment in which my code is executing, and I enjoy taking advantage of that.) Since the Travis virtual machine is Ubuntu, and we want to run the latest version of lintian (a Debian packaging "lint" checker), we run lintian within the Debian sid pbuilder. To do that, I use the glorious "B90lintian" sample pbuilder hook script, which comes bundled with pbuilder in /usr/share/doc/pbuilder/. The full build, which includes creating a sid pbuilder from scratch, takes merely 7-10 minutes. I personally find this kind of shockingly speedy -- in 2005, when I first got involved, doing a pbuilder build seemed like it would take forever. Now, a random free shell service on the Internet will create a pbuilder, and do a test build within it, in about 5 minutes.

Package review, without automation I've done package review for other mentees in the past. I tend to do it in a very bursty fashion -- one weekend day or one weeknight I decide sure, it's a good day to read Debian packages and provide feedback. Usually we do it asynchronously on the following protocol:

1. I dig up an email from someone who needed review.
2. I read through the packaging files, doing a variety of checks as they occur to me.
3. If I find problems, I write an email about them to the mentee. If not, success! I sign and upload the package.

There are some problems with the above:

• The burstiness means that if someone fixes the issues, I might not have time to re-review for another month or longer.
• The absence of an exhaustive list of things to look for means that I could fail to provide that feedback in the first round of review, leading to a longer wait time.
• The person receiving the email might not understand my comments, which could interact really badly with the burstiness.

I did this for Simon Fondrie-Teitler's python-pypump package recently. We followed the above protocol. I wrote a long email to Simon, where I remarked on various good and bad points of the packaging. It was part commentary, part terminal transcript -- I use the terminal transcripts to explain what I mean. This is part of the email I sent:

I got an error in the man page generation phase -- because at 
build-time, I don't have requests-oauthlib:
make[2]: Leaving directory  /tmp/python-pypump-0.5-1+dfsg/docs'
help2man --no-info \
	-n 'sets up an environment and oauth tokens and allows for interactive testing' \
        --version-string=0.5.1 /tmp/python-pypump-0.5-1+dfsg/pypump-shell > /tmp/python-pypump-0.5-1+dfsg/debian/pypump-shell.1
help2man: can't get  --help' info from /tmp/python-pypump-0.5-1+dfsg/pypump-shell
Try  --no-discard-stderr' if option outputs to stderr
make[1]: *** [override_dh_auto_build] Error 1
This seems to be because:
   python-pypump-0.5-1+dfsg  ./pypump-shell 
Traceback (most recent call last):
  File "./pypump-shell", line 26, in <module>
    from pypump import PyPump, Client
  File "/tmp/python-pypump-0.5-1+dfsg/pypump/__init__.py", line 19, in <module>
    from pypump.pypump import PyPump, WebPump
  File "/tmp/python-pypump-0.5-1+dfsg/pypump/pypump.py", line 28, in <module>
    from six.moves.urllib import parse
ImportError: No module named urllib
$ ./pypump-shell 
Traceback (most recent call last):
  File "./pypump-shell", line 26, in <module>
    from pypump import PyPump, Client
  File "/tmp/python-pypump-0.5-1+dfsg/pypump/__init__.py", line 19, in <module>
    from pypump.pypump import PyPump, WebPump
  File "/tmp/python-pypump-0.5-1+dfsg/pypump/pypump.py", line 29, in <module>
    from requests_oauthlib import OAuth1
ImportError: No module named requests_oauthlib

The deeper problem was a missing build-dependency, and I explained that in my email. But the meta problem is that Simon didn't try building this in a pbuilder, or otherwise clean build environment. Simon fixed these problems, and submitted a fresh package to Paul Tagliamonte and myself. It happened to have some typos in the names of the new build dependencies. Paul reviewed the fixed package, noticed the typos, fixed them, and uploaded it. Simon had forgotten to do a test build the second time, too, which is an understandable human failure. There was a two-day delay between Simon's fixed resubmission, and Paul signing+uploading the fixed result. In a pedagogical sense, there's something disappointing about that exchange for me: Paul fixed an error Simon introduced, so we're not teaching Simon to take total responsibility for his packages in Debian, nor to understand the Debian system as well as he could. (Luckily, I think Simon already understands the importance of taking responsibility! In this case, it's just a hypothetical in this case.)

For the future The next time I review a package, I'm going to try to do something similar to my Travis-CI hack. It would be nice to have the do.sh script be a little more abstract; I imagine that as I try to use it for a different package, I'll discover the right abstractions. I'd love it if Travis-CI did not require the git repositories to be on GitHub. I'd also like if the .travis.yml file could be in a different path. If so, we could create debian/travis-configuration (or something) and keep the packaging files nice and separate from the upstream source. I'd also love to hear about other people's feedback. Are you doing something similar? Do you want to be? Would you have done some of this differently? Leave a comment here, or ping me (paulproteus) on #debian-mentors on irc.debian.org (aka irc.oftc.net). I'll leave you with some conversation from #debian-mentors:

<paulproteus> The automation here, I think, is really interesting.
<paulproteus> What I really want is for mentees to show up to me and say "Here is my package + build log with pbuilder, can you sponsor it please?"
<Unit193> Oooooh!
-*- Unit193 gets ideas.
<paulproteus> Although the irony is that I actually like the community-building and relationship-building nature of having these things be conversations.
<bremner> how will this brave new world cope with licensing issues?
<paulproteus> bremner: It's not a replacement for actual review, just a tool-assist.
<paulproteus> bremner: You might be relieved to know that much of Unit193's and my back and forth related to get-orig-source and licensing. (-:
<bremner> I didn't doubt you ;).
<paulproteus> If necessary I can just be a highly productive reviewer, but I would prefer to figure out some way that I can get other non-paulproteus people to get a similar assist.
<paulproteus> I think the current blocker is "omg travis why are you bound to githubbbbbbbb" which is a reasonable concern.

This week, I started work on something I m calling moxie. Due to wanting to use my aiodocker bindings on the backend, I decided to implement it in 100% AsyncIO Python 3.4. What pushed me over the edge was finding the aiopg driver (postgres asyncio bindings), with very (let me stress - very) immature SQLAlchemy support.

Unfortunately, no web frameworks support asyncio as a first-class member of the framework, so I was forced into writing a microframework. The resulting app looks pretty not bad, and likely easy to switch if Flask ever gets support for asyncio. One neat side-effect was that the framework can support stuff like websockets as a first-class element of the framework, just like GET requests. Moxie will be a tool to run periodic long-running jobs in a sane way using docker.io. More soon!

We re now in the middle of the talk submission period. Our new web interface doesn t allow to show all the proposals and we decided to start accepting some talks in order to inspire you to propose your own talks.

• Outsourcing your webapp maintenance to Debian
• bugs.debian.org Database Ho!
• use Perl; # Annual meeting of the Debian Perl Group
• Status of the Debian OpenPGP keyring
• seeing Debian through a Functional lens
• Debsources: powering sources.debian.net
• A glimpse into a systemd future
• New Network Interface Manager for Debian: ifupdown2

If your talk is not on the list doesn t mean is not accepted, don t panic! And now, we re calling you all to bring up your best Debian-related ideas, proposals, stories. To think about what you want to organize a discussion on. Which tracks would you like to coordinate or see populated with interesting talks. Talks are the main ingredient for a successful, interesting, discussion-sparking DebConf. Don t be shy, and read how to submit your talk

Only a very short summary in English: I am Mexican. I am Jewish. I am almost completely disconnected from the local Jewish communities. And understanding the local Jewish communities is hard. There is a very interesting and brave campaign, recently started, called Neither do I The Mexican Jewish gay activist group Guimel, started off with this video (with English subtitles, if you are interested in following along). But how did I learn about this very bold initiative? By getting a hateful spam, inviting people to join a hate campaign. Right, the hate mail is not calling to violence, but it is based on premises as stupid as everybody's right not to include (to begin with). So, the least I can do about this is to share both said hate mail and publicly denounce my shock on reading this nonsense nowadays. And, also in Spanish (I know many people following me don't understand it Sorry, it would just take too long, and after all, it's mainly for local "consumption"), this is the reply I sent to them (and to the other recipients). Sorry in advance to the Spanish speakers for my exabrupts :) This was written "as is", without much prior thought, and quite angry about what I had just read.

Buf... Expresiones como esta, que hacen evidente la cerraz n de tanta gente en las comunidades jud as, justifican claramente por qu tantos nos hemos ido abriendo, integr ndonos a la sociedad circundante. Me da verg enza ser asociado como jud o a comunidades donde se defienden estos puntos de vista; si bien yo no soy de la comunidad Monte Sinai (como resultar obvio por mi nombre), para la sociedad en su conjunto s soy un jud o (as , a secas: Jud o). Mucho nos hemos quejado colectivamente a lo largo de los siglos acerca de la discriminaci n, de que seamos considerado la "basura" del mundo, los "apestados". Y es precisamente esa actitud, ante todo y en todo momento, lo que me ha llevado a alejarme del juda smo. Soy un ser humano m s, con una historia personal nica, con una historia cultural compartida pero tambi n nica, con algunas elecciones y algunas caracter sticas que me son inherentes nicas. Algo de eso no le gusta a alguien? Por motivos racionales o irracionales? No lo puedo ni pienso evitar. Pero el que una comunidad completa sea llamada a ignorar, humillar, alienar a sus hijos, por una estupidez as de anacr nica (en el caso que lo presenta el video al que hacen referencia, y a la gente que valientemente ha conformado Guimel) me parece que simplemente va m s all de toda estupidez. Piensen bien antes de adherirse a esta campa a de odio. Substituyan la sexualidad por cualquier otra raz n en la que somos minor a. No les da asco vivir con un vendedor de telas? Con un jud o apestoso? Y s , aqu ya estoy yo tambi n dejando ir a esos demonios... que hay que mantener bajo control. Porque somos hombres y mujeres de nuestro siglo, y porque el mundo y las nuevas generaciones merecen nuestro mejor esfuerzo para ir colectivamente destruyendo la estupidez de nuestros ancestros. Seamos m s racionales. Dejemos el odio, dejemos los prejuicios. Aceptemos a los diferentes, porque todos queremos que nos acepten. Porque todos somos diferentes.

Attachment	Size
tambien.txt	8.55 KB

The GnuTLS 3x transition is slowly starting. If you are maintaing a package (build-)depending on libgnutls-dev please test/consider building against libgnutls28-dev. TIA

On many occasions I ve seen discussions about the background knowledge that people are expected to have to contribute to FOSS projects. Often the background knowledge is quite different from the core skills related to their contributions (EG documentation mark-up skills required for coding work or knowledge of code required for writing documentation). One argument in favor of requiring such skills is of the form anyone who s good at one aspect of the project can learn skills for the other areas . Another is of the form anyone who has time to contribute in one area has time to learn all the other areas, anyone who doesn t want to learn is being lazy . I think it s reasonable that someone who is considering donating their time to a project would want to start doing something productive immediately. If someone has to spend many hours learning how things work before contributing anything of value they may decide that it s not a good use of their time or just not fun. Also if the project is structured to require a lot of background knowledge then that will increase the amount of time that long-term contributors spend teaching newbies which is another way of sucking productive energy out of a project. I don t think it s lazy to want to avoid learning unusual tools before starting a project. Firstly there is the issue of wanting to make productive use of your time. If you have a day for FOSS contributions and you can choose between spending 6 hours learning an environment for one project or 1 hour for another project then there s a choice of 2 hours or 7 hours of productive work. Someone who has the luxury of being able to spend several days a month on FOSS projects might think it s lazy to want to make effective use of 1 day, but there are a lot of people out there who are really busy and can only spend a few days a YEAR contributing, spending half a day learning an obscure development environment or documentation system can take a significant amount of someone s yearly time for such work. To make things even worse some of the best programmers are the ones who have little free time. For documentation MediaWiki (the software behind Wikipedia and Wikia.com) has a lot going for it. While it s arguable that it s not the best Wiki software out there (many people have wanted to argue this with me even though I don t care) it s obvious that MediaWiki is the most widely used Wiki software. If you have documentation stored in MediaWiki then most people who have any exposure to the IT industry, the FOSS community, or the Internet in general will already have experience using it. Also Wikipedia serves as a large example of what can be done with MediaWiki, there have been more than a few occasions when I have looked at Wikipedia for examples of how to layout text. Some people might think I m lazy for never reading the MediaWiki documentation, but again I ve got lots of other things to do and don t want to spend a lot of time learning about MediaWiki instead of doing more useful things like creating content. Project source code should be as consistent as possible. While large projects may have lots of modules and dependencies it s best to try and keep them all in one place. If your project depends on libraries of code from other sources then it s helpful to distribute copies of those libraries from the same location as the project source particularly when the project depends on development versions of libraries. Then if there s any mismatch between versions of libraries it will be a clear unambiguous bug that can be reported or fixed instead of being an issue that requires checks of what versions everyone is using. One thing we should aim for in FOSS projects is to get the long tail of contributions. If someone spends a day fixing bugs in a dozen projects to get their own system working as desired then it would be good if they could submit patches without excessive effort at the same time. This doesn t just apply to FOSS development, it also applies to a large extent to any collaborative project on the Internet. For example if I was to start a Wiki for fans of a sci-fi series wikia would be the first option I d consider because most potential contributors know it. Proprietary Software Development I ve seen all the same problems when developing proprietary software. The difference is that money and morale is wasted instead of contributions. Often in commercial projects managers choose products that have a good feature list without considering whether all their staff need to be retrained. Programmers can usually train themselves so it s often a hidden cost, the training is paid for in lost development time (both directly in time spent learning and indirectly when people make mistakes). One significant advantage of using free software on Windows is that programmers can play with it on their own. For example I ve never done a fresh installation of SourceSafe or ClearCase, but if I was going to work on a project that involved Git or Subversion on Windows then I could play with it and learn without risking disruption to the rest of the team. If commercial software is to be used then being common and relatively cheap is a significant advantage. MS SourceSafe offers significant benefits over most version control software on Windows simply because the vast majority of Windows developers have already used it and because it s cheap and easy to setup a test instance if necessary. I don t care about the success or failure of proprietary software projects in general (I only care when I m paid to care). I also don t expect that people read my blog with the aim of getting advice on running successful proprietary software development projects. This section is merely to illustrate the general nature of such wasted effort on collaborative projects and I should put my observations of failing proprietary software development projects to use. Debian Some Debian Developers are having a discussion about such things at the moment. That discussion inspired me to write this post. But I m mostly writing about my experience over the course of 20+ years working in the IT industry and contributing to FOSS projects not in a direct response to the Debian discussion (most of which I haven t yet read).