Review: Lockstep, by Karl Schroeder

Publisher:	Tor
Copyright:	March 2014
ISBN:	0-7653-3726-6
Format:	Hardcover
Pages:	351

Toby McGonigal's family fled an Earth dominated by trillionaires and vicious class conflict, and attempt, instead, a very risky and precarious settlement on a trans-Neptunian object. It's the last unclaimed but marginally habitable space left in the solar system, and securing their claim requires constant bureaucratic hoop-jumping. That's what sent Toby on a solo mission to a distant moon of their home to claim it and solidify their title. But, while in cold sleep, his craft hits a small chunk of rock, and he wakes up near another world: cold, silent, dead... but apparently with lifeless cities. Another trip through suspended animation in a desperate attempt to conserve resources against the distant hope of rescue has him awakening in a society both utterly foreign and yet strangely familiar. Schroeder is one of the better big idea writers in science fiction, but I found Lockstep to be a mixed bag. He does a surprisingly good job with the core conceit of the novel (more on that in a moment), even though it's a tricky one to make believable. Surrounding that, though, are a lot of less convincing bits that I kept having to not think about too hard, such as Toby crossing the path of another trans-Neptunian object after the accident (space is really, really big and really, really empty), or the implications of later revelations about the time scales involved in parts of the plot. Some parts of the world building, even if scientifically plausible, struck me as sloppy; for example, a religion plays a prominent role in the plot, but the nature of that religion was not particularly believable, nor was its interaction with the plot climax. I won't go into details about the religion, since it's a major plot point, but the short version is that religions tend to mature from the concrete to the abstract, not the other way around. That said, the core conceit is both surprising and considerably better-defended in the book than I thought it could be. The world into which Toby awakes is the world of the locksteps: a society that uses suspended animation in a universal and coordinated way to build a functional society on the far outskirts of the solar system. Humans emerge for some short period of time, like a month, and build, trade, interact, and consume. They welcome ships traveling from other trans-Neptunian worlds and prepare for their own journeys. And then they go into suspended animation for an extended period 15 years and 30 years are common choices while robots slowly gather more resources and energy, and repair and replace what's consumed in the month of active life. Ships travel with passengers in suspended animation, allowing the vast distances between these cold worlds to be reached during the sleep period. And, since all members of the lockstep sleep and wake on the same schedule, there is no wrenching desynchronization with the surrounding society during travel. One may spend thirty years in transit, but no time passes for anyone else in the lockstep while you're traveling either. A world can effectively trade with all other worlds within a thirty year travel radius without noticing the elapsed time. This is a technological system that at first doesn't sound like it would work, but Schroeder does a great job defending it and chasing down implications. The lockstep civilization serves as a sort of anchor and time capsule separate from the more frantic pace of the so-called fast worlds. The trans-Neptunian lockstep worlds are remote enough and poor enough to not attract too much unwanted attention, and are thus tolerated by fast societies that may have more available resources. (Although, to be sure, automated robot defenses have to carry a lot of weight here given how helpless the locksteps are during a sleep cycle.) I'm not sure I completely bought the sociology, but it works well enough to carry the weight of the story, and I've never seen a science fiction construction that uses the common technology of suspended animation in quite this way before. Schroeder sets up some nice stabilizing tensions between resources and time, adds some believable political reasons for this fragile society to survive, and uses some of its obvious political vulnerabilities as story drivers. The plot, unfortunately, isn't as good as the big idea, and particularly suffers at the start of the book. Toby is a teenager without much experience (Lockstep is marketed as young adult), and is immediately thrown into a strange and quickly hostile environment. This means that he spends the first half of the book reacting to a blizzard of new information, and the plot tends to revert to a tour of Schroeder's constructed world. Toby is also a bit of a cipher and a bit of an everyman, without many feelings or opinions beyond the obvious feelings that any teenage boy would go through in this situation. That makes the sense of a world tour even stronger. This flaw does not persist through the whole book. Toby does eventually start making decisions and doing things, some of the supporting characters add additional depth, and I found the unwinding of the plot surprisingly satisfying. The nature of time in this world lets Schroeder have both epic sweep and personal connection at the same time, which lets him pull off some neat contrasts between the personal and the political. I also liked Toby's gradual piecing together of what actually happened while he was asleep, both in the construction of society as a whole and in the personal conflicts between people he knew well. Some of the ease of grand manipulation seemed dubious to me, but, in Schroeder's defense, people do develop a reverence for and stories about things that have lasted a very long time, and Schroeder's setup gives him quite a lot to work with in that department. So, a mixed bag. The core concept is thought-provoking and up to Schroeder's usual standards. The surrounding world-building isn't as much, and I think Schroeder reaches for some too-easy explanations and still underplays just how many disruptive things can happen over the span of time that this book covers. The characterization I found weak and unsatisfying for much of the book, but it gets moderately better in the end. There's a bit too much tour, and a bit too much world exploration instead of plot, but it's a fascinating world and I still enjoyed the tour. With stronger characters and a few fewer dubious supporting pillars in the world background, I think this would have been an excellent book. As is, it's an enjoyable novel set firmly in the big idea and deep future end of science fiction, and I'm always happy to see more stories like that. It's not the best that Schroeder has done, but I still recommend it. Rating: 7 out of 10

John Scalzi wrote an insightful post about the utility of blog comments with the way the Internet works nowadays [1]. He starts out focusing on hate comments that could reasonably be described as terrorism (death threats with the aim of preventing people writing about politics meet any reasonable definition of terrorism ). Terrorists on the Internet are a significant problem but it s one that doesn t get much attention as it generally only affects people who aren t straight-acting white men. Blogging About Technology One corner case that John doesn t seem to consider is that of writing about technology. Issues related to programming often aren t related to politics and are often testable so comments will be based on things that have been shown to work rather than stuff people invent or want to believe. I ve received many useful and educational comments on my technical posts with little hostility. Even getting a snarky comment is rare when writing a strictly technical blog post. The comments problem for technology blogging is spam. I ve been using the WordPress plugin Block Spam by Math [2] (which is obsolete but still works) for years. Initially it stopped almost all spam, but now I m getting at least 20 spam comments a day. Extremely Popular Blogs The comments section of a blog is sometimes described as a conversation . When a blog post gets comments from less than 10 people it is possible for them to have something that resembles a conversation with the author that is of benefit to other readers and doesn t take excessive amounts of time for the author. When a blog is very popular and every post gets comments from 50+ people it s not really possible. So a traditional blog comment section seems to work best when the blog is primarily read by a small well connected group of people who sometimes comment and some casual readers who never comment (but sometimes find value in the comments of others). Discussions of blog comment systems usually include a reference to a post written by someone who disabled comments on their blog and found it to be a good thing, it always seems that the person who writes such a post has a large and varied audience who s comments would take a lot of time to moderate. John followed the usual form in this regard by linking to a reasonably popular SF author who would presumably have a lot of fans with good net access. I m not going to criticise anyone for disabling comments when their blog becomes really popular, but any advice that they have to offer about such things won t apply to the vast majority of blogs. Due to the long-tail effect the small blogs would probably comprise the majority of all comments so in terms of the way the blog environment works I don t think it makes much difference when the small minority of very popular blogs disable comments. The vast majority of blogs that I regularly read only have a small number of comments. One thing that should be noted is that getting a lot of readers shouldn t be the only factor for writing a successful blog. For example some of my blog posts about SE Linux are aimed at a small audience of Linux programmers and have an even smaller number of people who are qualified to comment. When I write a post that can only receive comments other than please explain more because I don t understand from a few dozen people that doesn t make it any less important. Sometimes the few dozen people who know a topic well need to work together to educate the few thousand who can implement the ideas for the benefit of millions of users of the software. Disabling Comments on Contentious Posts One interesting method John uses is to disable comments early when posting about contentious issues. It s a general practice when running a blog to disable comments on posts after a certain period of time (3 months to 1 year seem to be common time limits for comments). This means that the moderators can concentrate on recent posts and not be bothered with spam bots hitting ancient posts as the interest in writing legitimate comments on an old post is vanishingly small. John has a practice of disabling comments after a couple of days when the comments start to lose quality. No matter how contentious the issue is I m not likely to get the 400+ comments that John gets. But the idea of closing comments quickly still has some merit for my blog and other blogs with less traffic. Not Accepting Comments While Asleep John has a practice of closing comments while he s asleep to avoid allowing a troll to get 8 hours of viewing for a nasty comment. The most immediate down-side to that is that it inconveniences people who don t want to wait 8 hours to comment and prioritises comments from people in the same time zone, this makes me think of Cory Doctorow s novel Eastern Standard Tribe (which is available for free download and I highly recommend reading it) [3]. It seems that a better solution to that problem would be to have a team of moderators to watch things 24*7 which is what a lot of popular blogs that allow comments do. The WordPress capabilities model doesn t support granting a user no special privileges other than moderating comments [4], as WordPress is the most popular self-hosted blog software this limits the possibilities for people moderating comments on other people s blogs. No variation of this would work for me. I have lots of things that require my ongoing attention and don t want to add my blog to the list. If I have other things to work on for a few days I want to just not bother with my blog. This means that my blog needs to be able to run on autopilot for days at a time however I do monitor my blog closely after publishing a post that is likely to attract nasty comments. One extra problem that I have is that the Android client for WordPress has problems in synchronising comments. Using a Forum for Comments Popular Planet installations such as Planet Debian and Planet Linux Australia syndicate more than a few blogs that have comments disabled. A forum installation for such a Planet would be useful to allow people to comment on all posts and also support bloggers who are thinking of disabling comments. While the use of a forum for blog comments has been proven to work well for Boing Boing forums have their own issues of spam and anti-social behavior. Debian already has a forum [5], if a section of that was devoted to discussing blog posts from Planet Debian then it shouldn t make much of an increase to the work of the forum administrators while providing a benefit to the community. Also if the Debian forum had such a section it would probably attract use from more Debian Developers, I would use that forum if it was a place to comment on blogs that don t have a comment section and I might also comment on other forum discussions. It would be good if there was a forum for discussing Linux in Australia. I m not volunteering to run it but I would help out if someone else wants to be the main sysadmin and I can offer free hosting.

• [1] http://whatever.scalzi.com/2013/08/28/various-thoughts-on-online-comments/
• [2] http://wordpress.org/plugins/block-spam-by-math/
• [3] http://craphound.com/est/?page_id=1574
• [4] http://codex.wordpress.org/Roles_and_Capabilities
• [5] http://forums.debian.net/

Review: The Knowledge, by Lewis Dartnell

Publisher:	Penguin
Copyright:	2014
ISBN:	0-698-15165-8
Format:	Kindle
Pages:	328

The cover pitch for The Knowledge is that technological civilization has collapsed. A war, an asteroid, a pandemic, or some other catastrophic event has ended life as we know it. Survivors have recovered enough to stabilize the population, but all the industry and infrastructure that supports the modern world has been crippled and the knowledge lost. What do they need to know to rebuild the world? (The subtitle, How to Rebuild Our World from Scratch, is deceptive. Dartnell spends a lot of time talking about what could be scavenged from the ruins after an event like a pandemic that leaves buildings and tools intact.) This brief description may bring several incorrect ideas to mind, so a few clarifications are in order. First, this is not a book about how to survive an apocalypse, or how to stabilize society afterwards. Dartnell skips over anything related to basic survival or politics, and this book would only be of limited interest to preppers. Rather, it is focused on the key concepts and key processes that underlie much of what makes up our civilization, and how those processes can be bootstrapped and recreated, hopefully much more quickly than the thousands of years they took to develop the first time around. Second, as much as I think Dartnell would have liked it to be, The Knowledge is not an instruction manual. There's just too much involved in modern machinery, metallurgy, chemistry, and other necessary science and engineering. What it is instead is a tour of the most important ideas, basic processes, and approaches that can lead to creation of an industrial economy. This means it's also a tour of the most critical technology and discoveries that we rely on for day-to-day living. Each idea presented here is a bare sketch, and would require extensive research and experimentation to put into practice. The Knowledge is not a scientific encyclopedia. Rather, it's a collection of signposts and suggested directions along with some suggestions about sequencing, with special emphasis on the ideas that were unintuitive or surprising, or which took humans much longer to stumble across than would have been necessary. I will say up front that I am quite dubious about the stated goal of this book. I'm not sure if it would be of significant assistance to people who found themselves in the circumstances that Dartnell postulates, and I'm also not sure it would be as difficult as Dartnell supposes to reconstruct these details from a good library, although the point is well-taken that most modern industrial techniques would be unavailable to a civilization starting from scratch and many historic techniques are no longer practiced and therefore not well-documented. But this book does not have to succeed at its stated goal to be worth reading. The Knowledge provides a fascinating insight into the way our current capabilities developed, other paths that development could have followed, and what building blocks are vital for the industry that we rely on. If you are like me, the first thing The Knowledge will remind you of is Minecraft, particularly with some of the mods (such as TerraFirmaCraft) that add more realistic detail to the technological bootstrapping. It's a treasure trove for anyone who might be working on that sort of mod or game. Dartnell tries to cover as much of the spectrum of technology as possible, from farming through medicine, from basic materials to industrial chemistry, and from electrical power through transportation. Each chapter necessarily covers only the highlights, the most vital technologies and the early priorities, and many of those are relatively vague pointers. But that's enough for a fascinating orientation. It's also full of memorable trivia: the huge variety of uses to which wood can be put, the difficulty in re-establishing production of industrial acids, the shelf life of gasoline, the global seed vault within the Arctic Circle, and the importance of a long-threaded screw for a lathe, just to name a few examples. In short, The Knowledge may or may not be a practical aid in rebuilding the world, but it's a lot of fun to read and full of tidbits that are fun to think about or pass on to others. It's also a great orientation in applied technology. The Knowledge is particularly fascinating if you have any interest in the simplified recreation of technological and industrial processes, such as in Minecraft and similar games. For authors of Minecraft mods who are aiming for realism, it might even be required reading. I'd love to see more mods based heavily on the approaches described in this book. The Knowledge also conveys, better than any book or course I've seen, an intuitive feel for the amazing complexity and ingenuity underlying industrial technology. I pre-ordered a copy of this book as soon as I heard about it, and I was not disappointed. Despite my certainty that I would be one of the early casualties in any general social collapse, I thoroughly enjoyed reading it, and would like to read it again at some point. Recommended, albeit with the caveat that I do not have the background required to verify any of the facts in this book, and am assuming that Dartnell has done his research properly. Rating: 9 out of 10

DNSSEC is one of those things that have been on the I should poke at that sometime list, but today I decided to actually get in and play around with it. Turns out it s pretty trivially easy to setup, but I got bitten by a few gotchas during testing, that I thought worthwhile to document. Since I like to explain things, a lot of this article isn t how to so much as how does .

Configuring The Resolver First off, you need a resolver¹ that you can trust, and which implements DNSSEC validation. In theory, you could use your ISP s resolvers (if they re DNSSEC-enabled), or even Google s public resolvers (8.8.8.8 and 8.8.4.4), but it s really not recommended how much do you trust those, really? More importantly, how much do you trust the network path between them and you? Frankly, running a local on-host caching resolver is trivial, consumes next-to-no resources, and is highly recommended. It s what I did. I used unbound, finally casting free the venerable dnscache, which has served me well for many years. I chose unbound because it fits the do one small thing, and do it well philosophy that I cherish (unlike BIND), and because it s what all the cool kids appear to be using these days. Installing it was as simple as apt-get install unbound it s available in pretty much every distro, I believe. Out of the box, unbound in Debian wheezy comes configured for DNSSEC validation. Other methods of installation might not be so amenable, so just make sure your unbound.conf liiks like this, so that DNSSEC is enabled:

server:
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    val-log-level: 2

The val-log-level line isn t strictly required, but I found it useful to have unbound log info on validation failures to syslog. Season to taste. You also have to configure your system to actually use your new, shiny local resolver. Editing /etc/resolv.conf would, in an ideal world, work Just Fine, but between Magical Unhelpful Pixies (I m looking at you, NetworkManager) and DHCP, it often isn t that easy. Ultimately, though, you should configure your system so that the only resolver in /etc/resolv.conf is always 127.0.0.1. Anything else is a security hole waiting to happen. If you re using DHCP and a recent version of ISC dhclient, adding supersede domain-name-servers 127.0.0.1; to dhclient.conf should do the needful.

Weighing the (Trust) Anchor Whatever local resolver you choose, you need to tell it about trust anchors . This is a key (or keys) which are trusted to sign all the other data that the resolver will find. Like the rest of the DNS, DNSSEC is hierarchical, and you need to know who to start with before you can start. To resolve a name using DNS, you ask the root servers for the answer to a question (say, what is the address of www.example.com? ). The root server doesn t know the answer, but it knows who to ask, and it tells you where to go (typically, go ask the DNS servers for .com, which are X, Y, and Z ). Then you ask those servers, and they probably don t know, but they know who to ask, and they tell you to go ask those servers. This continues until you finally get a server which says, oh, yes, I know the answer to that! and hands over the information you re after. In DNSSEC, you get digital signatures that prove that the answers you get from each DNS server you ask are legit, and not forged. So when you ask the root servers, what is the address of www.example.com? , they answer, I don t know, but go ask DNS servers at addresses X, Y, and Z and by the way, you can trust this answer is legit because here s this signature you can check . To verify a signature is legit, you need to know that the key used to make the signature is trustworthy, and it wasn t just any ol key that made it similar to how an ink scribble on a page doesn t mean anything unless you know what the signature you re looking at should look like. DNSSEC has two ways to make sure you know who to trust. Firstly, those trust anchors I mentioned three paragraphs ago. These are the keys that the root servers use to sign the responses they send out. You tell unbound (or your local DNSSEC-enabled resolver of choice), if you see a signature provided by this trust anchor key, you can trust it to be legit . The second way to trust is key is to have someone you already trust say, oh, you can trust this key, too . This is done by providing more data in the answer that you get from the root servers. So the full answer you get from the root servers when you ask, what is the address of www.example.com? looks like this:

I don t know, but you should ask the DNS servers at addresses X, Y, and Z. You can trust their answers because they ll sign their responses with key K. Finally, you can trust that I m legit because of this signature I m providing you, generated from key T.

Assuming that T is the trust-anchor key you ve already told unbound to trust, it can then trust all of the information it got from that first question. When it then goes to DNS server X and asks, Hey, do you know the address of www.example.com? , that server can send back its own response saying:

Gee, shucks, I don t know, but DNS servers at P and Q can help you. You can trust them because they ll sign responses with key S. And just to show you I m on the level, check out this nifty signature I made, signed with key K.

Since a server we trust told us to trust key K, and then we got a response signed by key K that told us to trust key S, when we then go and ask server P and get a response signed by S, we re still demonstrably secure. Neat setup, right? Anyway, now you know all about trust anchors. How do you set it up? For unbound, it s capable of priming the trust anchor itself. It does this by retrieving a copy of the trust anchor from [a well-known HTTPS URL]((https://data.iana.org/root-anchors/root-anchors.xml), which provides a reasonable measure of security the trust anchor file should be safe as long as that HTTPS server is trustworthy. For the properly paranoid, you should determine an alternate means of verifying that you have the correct root key (a web search for DNSSEC root key attestation would probably be a good start).

Testing It s always handy to know that something s working as you expect. For something that s important for security, that goes double. So, how do you test that your DNSSEC-capable resolver is, indeed, working as designed? Well, firstly, you can test that the resolver, by itself, is working. This is simple: do a query for a zone known to have broken DNSSEC. Thankfully, some nice people (Comcast, specifically) have already set this up. You can test a resolver for DNSSEC-correctness with this command:

dig @127.0.0.1 www.dnssec-failed.org

If dig gives you back an IP address, something is broken. The correct, my DNSSEC works! response should be a status: SERVFAIL response. That s all well and good, but having a resolver that works isn t much good if nothing s actually using it. Your system configuration has probably got some other resolvers configured into it (such as those provided by a DHCP server), and you ll want to make sure those aren t getting used². The trivial test is to visit http://www.dnssec-failed.org in your browser. If that comes back with a page, then something s still wrong. A more user-friendly test of your DNSSEC configuration is provided by http://dnssectest.sidnlabs.nl/test.php, which will display a page either way, and give you a tick or a cross depending on whether you re DNSSEC-enabled or not. One thing to be wary of when you re doing browser tests is caching. I spent far too long trying to work out why unbound wasn t working , when in actual fact it was working fine, it s just that both my browser and local caching proxy (squid) were caching DNS requests³. So, even after I d correctly setup unbound, visiting the test sites was providing me with erroneous results. Fixing up the browser was simple enough. In Chromium, visiting chrome://net-internals#dns will show you what s being cached, what resolv.conf settings are being used, and allow you to clear the browser s resolver cache. Squid was similarly simple, although it took me a while to figure out that it was causing me grief (software that just works , being so rare, tends to slip your mind, and so I often forget that squid is actually doing me good). Restarting squid has the appropriate result (clears the DNS cache), but in the end I decided that having another layer of caching wasn t going to help significantly when I ve got an on-host DNS cache already, in unbound. So, I just turned the knobs for DNS caching in squid right down:

negative_dns_ttl 1 second
positive_dns_ttl 1 second

And voila! All was well.

In summary DNSSEC is cool. It s easy to get going with, and over time it will provide more and more practical benefits (I am a DANE fanboi). Get started with it now, and you ll be ahead of the curve.

---

1. A resolver is a program which takes a name, does all the DNS queries required to get the data associated with that name, and return it to whoever wanted to know. This can be a library which links to a client application, or it can be a separate program which receives DNS requests itself. There are usually both types of resolvers in use for a typical Linux system to resolve names. On every machine, in every program, there is the so-called stub resolver , which is part of libc, and does nothing except create DNS requests and send them to the addresses listed in resolv.conf. Also present, although not always running on every machine (typically your ISP or network admin has some running for everyone to share) are one or more recursive resolvers , which are separate programs which take DNS requests, do all of the queries themselves, and return the result to the stub resolver for presentation to the client program which made the request in the first place. You will see this material again.
2. You can configure dhclient to use your local resolver instead of the DHCP-provided ones by simply setting:

   supersede domain-name-servers 127.0.0.1;
   

   in your dhclient.conf file.
3. It also didn t help that I hadn t correctly knobbled dhclient the first time around, and so even when I thought I was only resolving against my local unbound server, it was still actually using the DHCP-provided resolvers

Review: The Wilding, by C.S. Friedman

Series:	In Conquest Born #2
Publisher:	DAW
Copyright:	2004
Printing:	July 2005
ISBN:	0-7564-0202-6
Format:	Mass market
Pages:	551

In Conquest Born is a rather odd space opera, featuring an interstellar war between two great empires that culminates in an intensely personal struggle between leaders of the two sides. It has one of the most intensely misogynistic societies in science fiction (the villains, yes, but weirdly ambiguous villains), genetic breeding programs for telepaths, and a host of unlikable but oddly fascinating characters. I thought it was weaker on re-read than I remembered it being originally, but it's still singular enough in memory that I wanted to read the sequel. The Wilding picks up in the same universe a century and a half later. I expected more of a direct connection to the plot of In Conquest Born, but I think this book could be read on its own. (This is good, given how the plot of In Conquest Born tends to slip out of my memory, despite how unique the book is.) The Azeans and the Braxins are, of course, still at war, an on-again, off-again affair that neither side seems likely to ever win. But the Azeans have forbidden psychic powers and driven all psychics underground, if they still exist at all. They are supposedly too unstable to be allowed in the carefully constructed Azean society. Tathas is Braxin, but not from the ruling Braxan tribe. He is caught practicing old rituals of his native tribe and escapes sentence of death by going on the Wilding, an ancient practice of leaving Braxin culture to find new genetic material and bring it back to strengthen their species. Or, put in less euphemistic terms, to find and rape a woman and bring back the resulting child, although apparently retrieving a genetic sample would also work. Did I mention the misogynistic society part? Still there. Zara, the other primary protagonist, is an Azean mediator who, as the book is opening, starts developing psychic powers. This is a rather serious problem that gets her suspended from her job. Her check of her own genetic records (the old-school SF obsession with eugenics is also still there) leads to the discovery that she's an identical twin, whose sister was kidnapped as an infant under mysterious circumstances and apparently by underground psychics. Zara decides to go in search of her. As with In Conquest Born, this book is full of deeply unpleasant societies and world views. Also as with In Conquest Born, I don't think Friedman intends any of them to be held up as examples of correct politics or behavior. What makes both of these books unusual is that neither she nor the characters seem to be making any attempt to construct a third alternative that would be better. The secret society of psychics has a different appeal, but it's not clear the characters would want to be part of it either, and it's quite possible that they're still responsible for a lot of the crap that's going on in the galaxy. The book feels like it ought to be political, as these societies are clearly broken and deeply abusive (the Braxins more obviously than the Azeans, but they're both creepy), but it mostly isn't. Instead, The Wilding is focused on individual people trying to make their way in this world. Those people come from varying strata of these societies. Zara and Tathas are there throughout; other characters crop up briefly with their own viewpoints and then often go away again or are killed. I think Friedman is going for a story of raw emotion and a tight focus on individual actions, with little in the way of clean morality or broader morals. And yet... the final act of the protagonists in the book is a political act that seems aimed at making the universe a better place. In a way, this is a very cynical book: there is a tremendous amount of manipulation and political maneuvering, and it's hard to see any cause here that one can fully support. This is all rather similar to In Conquest Born, but what held the previous book together was its backbone of obsessive vengeance and the spectacle of two intelligent people from utterly different societies locked in all-out emotional and physical combat. The Wilding doesn't have that. It has characters with strong motives and strong emotions, but none of them are the sort of epic, transcendent emotions that propel mythic heroes at each other. This is a more prosaic and personal book, which means the drama isn't strong and sweeping enough to make the reader forget the deep unpleasantness that's going on around them. The Wilding feels less like a clash of titans and more like personal quests for identity against a universe full of awful people and worse systems. It also retains, in the Braxin, aggressive male-dominant sexuality just this side of a Gor novel, but here that feels seedier and even more squirm-inducing than it did in In Conquest Born. The Wilding is even more ambiguous about the ethics of that sexual and misogynistic abusiveness; Tathas partly gives it up, but this is presented more as an accommodation to another culture than as a real engagement with the inherent abusiveness of Braxin society. I still have no idea whether and to whom I would recommend In Conquest Born. I'm less torn about The Wilding: don't bother. It's a lesser work in all respects, it shares some of the problems with too many characters and an occasionally incoherent plot, and I had even more trouble with the horrible societies Friedman creates than I did in the previous book. And it doesn't have the same counterbalance of epic, uncontrolled emotions and characters who seem to transcend the story they're in. Instead, it feels more like a story of damaged people in an awful universe who are meddling through as best they can while being manipulated by the people with real power. It got more depressing the more I thought about it, and the ending doesn't salvage the story. Rating: 4 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!

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).

Review: A People's History of the Supreme Court, by Peter Irons

Publisher:	Penguin
Copyright:	1999, 2006
Printing:	2006
ISBN:	0-14-303738-2
Format:	Trade paperback
Pages:	553

I first encountered Peter Irons via his Teaching Company course, The History of the Supreme Court. I listened to that and enjoyed it, and would recommend it as an excellent overview. When I later ran across this book, I was excited: I usually prefer books to lectures on topics that can benefit from greater depth, and A People's History of the United States is one of my favorite history books. A book that talked about the Supreme Court from a similar bottom-up approach was appealing. Unfortunately, I think the title oversells this book. It is a history of the Supreme Court, and, as with Zinn's book, it carries its bias openly (if not as forcefully or compellingly as Zinn). It is a legal history concerned with individual rights, and Irons openly expresses his opinions of the merits of certain decisions. But it's not the full-throated cry for justice and for the voice of the general population that Zinn's book was, nor did I think it entirely delivered on the introductory promise to look at the people and situations underlying the case. It does provide more background and biographical sketch of the litigants in famous cases than some other histories, but those sketches are generally brief and focused on the background and relevant facts for the case. This is, in short, a history of the Supreme Court, with some attention paid to the people involved and open comfort with an authorial viewpoint, but without the eye-opening and convention-defying freshness of Zinn's refusal to point the camera at the usual suspects. It also largely duplicates Irons's course for the Teaching Company. That's only really a problem for those, like me, who listened to that course already and came to this book looking for additional material. If you haven't listened to the course, this is a reasonable medium in which to provide the same content, although you do miss the audio recordings of actual Supreme Court argument in some of the most famous cases. But after having listened or read both, I think I prefer the course. It felt a bit more focused; the book is not padded, but the additional material is also not horribly memorable. That said, as a history, I found this a solid book. Irons opens with a surprisingly detailed look at the constitutional convention and the debates over the wording of the US Constitution, focusing on those sections that will become the heart of later controversy. Some of them were known to be controversial at the time and were discussed and argued at great length, such as anything related to slavery and the role of a bill of rights. But others, including many sections at the heart of modern controversies, were barely considered. Despite being a bit off-topic for the book, I found this section very interesting and am now wanting to seek out a good, full history of the convention. Irons's history from there is primarily chronological, although he does shift the order slightly to group some major cases into themes. He doesn't quite provide the biographies of each Supreme Court justice that he discussed in the introduction, but he comes close, along with discussion of the surrounding politics of the nomination and the political climate in which they were sitting. There's a bit of an overview of the types of cases each court saw, although not as much as I would have liked. Most of the history is, as one might expect, focused on more detailed histories of the major cases. Here, I was sometimes left satisfied and sometimes left a bit annoyed. The discussion of the Japanese internment cases is excellent, as you might expect given Irons's personal role in getting them overturned. The discussion of the segregation cases is also excellent; in general, I found Section V the strongest part of this book. Irons also does a good job throughout in showing how clearly political the court was and has always been, and the degree to which many major decisions were pre-decided by politics rather than reasoned legal judgment. Where I think he fails, however, is that much of this book has little sense of narrative arc. This is admittedly difficult in a history of a body that takes on widely varying and almost random cases, but there are some clear narratives that run through judicial thinking, and I don't think Irons does a good enough job telling those stories for the readers. For example, I remembered the evolution of interpretation of the 14th Amendment from freedom of contract to the keystone of application of the Bill of Rights to the states as a compelling and coherent story from his course, and here it felt scattered and less clear. In general, I liked the earlier sections of this book better than the later, with Section V on the Warren court as the best and last strong section. Beyond that point in the history, it felt like Irons was running out of steam, and it was harder and harder to see an underlying structure to the book. He would describe a few cases, in a factual but somewhat dry manner, make a few comments on the merits of the decision that felt more superficial than earlier sections of the book, and then move on to another case that might be largely unrelated. Recent judicial history is fascinating, but I don't think this is the book for that. Irons is much stronger in the 19th and first half of the 20th centuries; beyond that, I prefer Jeffrey Toobin's The Nine, which also has far deeper and more interesting biographies of recent justices. This is not a bad history of the Supreme Court. If you're looking for one, I can recommend it. But if you're flexible about format, I recommend Irons's course more. I think it's less dry, better presented, and flows better, and I don't feel like you'll miss much in the transformation of this book into an 18 hour course. It's also remarkable to hear the actual voices of the lawyers and justices in some of the landmark cases of the middle of the 20th century. But if you specifically want a book, this does the job. Do also read The Nine, though. It's a good complement to Irons's straight history, showing much more of the inner workings, political maneuverings, and day-to-day struggles of the justices. Rating: 7 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

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 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.

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).