This week:

• #606151 (nordugrid-arc-nox): cherry-picked a patch from upstream and uploaded to DELAYED/1
• #606670 (minitube): removal bug filed at request of maintainer
• #607762 (dbus-glib): bumped the build-dependency and uploaded to DELAYED/7 (later pushed into DELAYED/0 at maintainer s request)
• #607427 (opensc): applied security fixes from upstream and uploaded immediately

Not quite one fix per day, as zack s campaign originally called for. But true to his word, neither have I started receiving hate mail, so I must be doing something right. (I also made my first sponsoring upload an RC fix (#598945), for extra brownie points <g>)

When I first started using Debian properly, I played with gpg-agent and pinentry but I didn t really understand the various bash initialisation scripts, and my botched setup annoyed me so much I disabled it again quite quickly (for example, if I left the machine logged in to GDM at home then logged in through SSH, pinentry dialogs stayed in GDM and had to be killed). Now I ve finally had time to get it sorted out, and this is part aide-memoire and part idiot check (hello, lazyweb). The brief:

• gpg-agent should take care of both GPG keys and SSH keys, transparently;
• pinentry should ask with pinentry-gtk2 at home, or at the current SSH session remotely;
• nothing should be left lying around after a session.

I assume appropriate packages are already installed at a minimum, gpg-agent and whichever pinentry you prefer. Installing gpg-agent drops a hook into /etc/X11/Xsession.d, but now there are both gpg-agent and ssh-agent running. Disable ssh-agent because we re going to let gpg-agent take care of everything: in /etc/X11/Xsession.options, comment out the line use-ssh-agent. In /etc/X11/Xsession.d/90gpg-agent, add the enable-ssh-support parameter so the STARTUP variable looks something like:

STARTUP="$GPGAGENT --daemon --sh --enable-ssh-support --write-env-file=$PID_FILE $STARTUP"

and also disable ssh in gnome-keyring:

$ gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false

Now (after restarting your X session) you can use ssh-add to import a key into gpg-agent, and you should see a pinentry dialog asking for a password. That takes care of X sessions, but it won t work for SSH. This is where the different bash login scripts matter: ~/.bashrc is run for all non-login shells (that is, ones spawned from e.g. gnome-terminal) but ~/.profile is only run for login shells (that is, ones where you have to authenticate, such as SSH connections). So, at the bottom of ~/.profile, we just start another gpg-agent who doesn t know about X:

eval $(gpg-agent --enable-ssh-support --daemon)

After restarting your SSH session and triggering a key operation, like signing a document, pinentry-curses should ask for your passphrase at the SSH shell and not leave dialogs stranded in the X session. Finally, that second agent shouldn t be left hanging around after we ve finished, or there ll be hundreds of them soon. Fortunately, the PID is recorded in the environment variable GPG_AGENT_INFO, but parsing that is a bit awkward when it s also recorded alone in SSH_AGENT_PID. So in ~/.bash_logout, we just

kill $SSH_AGENT_PID

(Most of the pointers for this setup came from http://wiki.kumina.nl/index.php/Managing_ssh_keys_with_gpg-agent and http://stefaanlippens.net/bashrc_and_others)

Now that it s much more convenient for me to do NMUs, and simultaneously there a handful of bugs that I can actually deal with, I guess it s about time I got stuck into some RC bugs. Here s my (rather modest) list of fixes for Squeeze the past few days:

• #606298 (deal.ii): can t be reproduced by two of us; closed
• #606657 (wordpress): new upstream release is a targetted fix, so applied and uploaded to DELAYED/5
  (maintainer made a proper upload shortly after)
• #606386 (cakephp): applied patch from upstream and uploaded to DELAYED/2
• #606293 (hol88): reverted the build-dependency bump on gcl and uploaded to DELAYED/5

This is a mental note really, since my certificates last two years and I ve always forgotten what to do about it.

1. Generate a new request:
   openssl req -new -key <keyfile> -out <csrfile>
   StartSSL throw away all properties of the request except the key, so any answers will do.
2. Re-use the request you sent last time (thanks Noel).
3. Get the certificate signed.
4. Dovecot expects a key in /etc/ssl/private/dovecot.pem and a certificate chain in /etc/ssl/certs/dovecot.pem. Build the chain, CERTIFICATE FIRST:
   cat <crt> sub_class2.pem ca.pem > /etc/ssl/certs/dovecot.pem
5. Reload Dovecot and test from somewhere remote:
   openssl s_client -connect <server>:imaps
6. Coffee time.

Lighttpd is basically the same, but additionally expects the key to be in the top of the certificate chain.

Boy, I wish that word worked. Today I had cause to email O2, the local Telefonica outpost, to have them disassociate my phone from the Cloud hotspot network, to which I get a subscription with my contract. This is so that I can associate my new Desire Z instead. I explained that I can connect to the AP, but when I enter my phone number to associate it is refused. Their considered response to this request was as follows:

As you re using a Palm Pre, I d request you to switch on Palm Pre by following the steps provided below

Of course, I m so silly I forgot to switch the phone on! Any suggestions for a UK SIM-only provider with a clue (and optionally including free use of Cloud hotspots)?

Last week I went to the sea side, and came back with a fianc e. Bliss.

I didn t quite believe what I was seeing until I searched and found several other people noticing the same behaviour. For background, Facebook recently introduced the concept of groups not in the sense we ve been used to, but more like lists. Groups are supposed to be to lists what databases are to bits of paper. You can add friends to groups to organise them, send them group emails, run a collective mailing list, and so on. Except that in practice, this is another really good way of exploiting lazy users. See, there are some things to know about groups:

• you don t have to opt in to one; friends can add you and that s it no confirmation necessary
• it seems that even if the group is closed, members can add other members without any controls
• if you re added and you switched off email notifications in general, you don t even know it
• the group gets an email address, which sprays inbound mail to every member until they get fed up and switch it off

The second point may be wrong it s very unclear exactly what permission is afforded to a group member and when or where information about the group membership is published. Since my day job is in private education, this immediately makes me think of two terrifying scenarios:

1. A student inadvertently gets added to a large group and nobody notices because there is so much other traffic. Whatever my other privacy settings, anything I or anyone else posted to the group is now visible to him this is the same as the previous group arrangement. The difference is that he can now go on and add anyone else Mark Zuckerberg himself even without any kind of checks by the group administrator. A membership system like this quickly spirals out of control.
2. Somebody with a grudge maybe I took too long fixing their PC adds me to a group with, shall we say, inappropriate or unsavoury content while I m away on holiday and tips off the child protection officer. Better yet, he first sends an email to all staff expressing horror and asking them to verify this in case it s his computer lying. Now there are multiple witnesses to the fact that I was a member of this group, and I return from the sea side to find a P45 on the door mat.

Unlike free software, I can t fix this. Fortunately, I have: enabled every email notification under the sun; few and trustworthy friends; according to my profile, no interests or contact details whatsoever; and no care for groups. I m happy with my lists, thanks all the same.

Please stop perpetuating the myth that any old grainy image can be enhanced beyond all recognition. It s not possible to read a newspaper at a thousand paces any more than it is to see around corners, even with a Really Big Computer. Every time one of my users brings me a photo and asks, can you make it really detailed like they do in CSI , I die a little inside. Love and kisses.

I came across the mingetty changelog by chance while researching something totally unrelated. Paul Martin, you are a genius.

mingetty (1.07-2) unstable; urgency=high
   * Critical security patch: Fix unsafe chroot call. (Closes: #597382)
   * Checked dependencies for locusts. (Closes: http://xkcd.com/797/)
  -- Paul Martin <masked>  Sat, 25 Sep 2010 01:51:12 +0100

Original cartoon: http://xkcd.com/797/

After the famous Facebook outage a few days ago, Facebook Engineering made a to be fair, reasonably detailed statement on what went wrong and how it affected the service. One particular comment attached to it drew my attention:

It s great to hear and see that big companies like Facebook are so open with what they do. That s rare, very rare. Thanks!

Huh? Did I miss some announcement of openness and freedom?
<script type="text/javascript"> var flattr_wp_ver = '0.9.16'; var flattr_uid = '32970'; var flattr_url = 'http://www.jwiltshire.org.uk/content'; var flattr_lng = 'en_GB'; var flattr_cat = 'text'; var flattr_tag = 'blog,wordpress,rss,feed'; var flattr_btn = 'large'; var flattr_tle = 'jwiltshire.org.uk'; var flattr_dsc = 'The public face of jwiltshire'; </script> <script src="https://api.flattr.com/js/0.5.0/load.js?mode=auto" type="text/javascript"></script>

Recently I was surprised to find that many of the rules I took for granted when dealing with an OpenPGP keyring, and the other activities associated with a web of trust, were new to some people I spoke to. These rules are born from a mixture of experience, accepted good practice, and wider reading, with a small dose of paranoia thrown in for good measure.

• Protect your secret keyring with file permissions. For GPG, your ~/.gnupg directory should not be readable by anybody else, including root (even though he could break in if he wanted). Mine is octal 700, and the secret keyring itself is 600.
• Create a revocation certificate, and keep online and offline copies (gpg --gen-revoke <keyid>). The revocation certificate is published to key servers by you in the event that you detect key compromise or loss. It s important that this is also well-protected, because the secret key is not required to upload it. Print a copy in bold and on good quality paper, so it will last a long time, and preferably keep them both off-site in a trusted location. Typing all those characters back in is a bore, but if your online copy fails it s better than being impersonated.
• Use a good pass-phrase, not a password. A pass-phrase is actually easier to remember than a string of random characters, without risk. It can be long enough to make brute-force attacks pointless, and if you re using the key a lot and can t be bothered to type it all the time, gpg-agent is a handy and safe tool. Your login password is not an acceptable pass-phrase for your secret key!
• Regularly refresh your public keyring from a well-connected keyserver. I detailed this in an earlier post; it s a case of calling gpg --refresh-keys once a week or so. This is the first line of defence against other people s keys being compromised, since without it you ll never know that your messages to them are now vulnerable. A well-connected server, like those in pool.sks-keyservers.net, matters since not all servers synchronise predictably.
• Rotate encrypting sub-keys regularly. This reduces the effect of a compromised key: if you rotate keys annually, a compromise only opens one year of mail. Small comfort, but every little helps. Don t delete the old keys though, just revoke them otherwise you won t be able to open mail from those senders who don t refresh their public keyrings.
• Keep your key offline and make a separated signing sub-key for day-to-day use. There isn t room to go into detail here, but you can export a signing sub-key with a relationship to your primary key material, so if it is compromised you can revoke it without losing all those carefully-collected signatures. The same goes for encrypting sub-keys. Adrian von Bidder has a guide to this, but he warns that it should be taken with a pinch of salt, so this isn t so much a rule as an interesting idea. I have not experimented with this yet.

And some rules about signing and signatures:

• Don t place too much store by signing parties. Parties are great for rapidly building a web of trust, but a part of that trust is to do with how the other party checks identities. I don t believe it s possible to establish that with just a few minutes chat and an identity check, so I never make a sig2 or sig3 on a key I met at a party. I m usually happy to do that later when I have an established relationship with the key holder, of course.
• Never upload your own signature to a key server. Apart from the fact that the key holder might not want their key published, you also have no way to prove that the key holder has access to the email address on their UID. It s much better to send the signature to them encrypted, which demonstrates that they the both key and can read mail at the address (the caff program is ideal for this).
• Give personal trust (the trustdb) carefully. Getting that message Good signature from in your mail client is really nice, but not at the expense of giving away trust where it is not deserved. In the same vein as not placing too much trust at signing parties, you should avoid the temptation to over-trust keys in your personal trustdb. Reputation on a mailing list is absolutely no substitute for observing the party taking care over their verifications when doing face-to-face signings.

Do you have other rules or guidelines that you use when dealing with keys and signatures?

I got this in my Debian mailbox the other day (it s an invitation to Facebook, in French):

Bonjour Jonathan,

Je vous ai invit rejoindre Facebook r cemment et je voulais vous rappeler que d s que vous serez enregistr , vous pourrez vous connecter [...]

Poete Bellon a invit xxx@xxxx rejoindre Facebook. If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe.

<script type="text/javascript"> var flattr_wp_ver = '0.9.12'; var flattr_uid = '32970'; var flattr_url = 'http://www.jwiltshire.org.uk/content'; var flattr_lng = 'en_GB'; var flattr_cat = 'text'; var flattr_tag = 'blog,wordpress,rss,feed'; var flattr_btn = 'large'; var flattr_tle = 'jwiltshire.org.uk'; var flattr_dsc = 'The public face of jwiltshire'; </script> <script src="https://api.flattr.com/js/0.5.0/load.js?mode=auto" type="text/javascript"></script>

(this is a post in two parts) At the BoF of GPG Key Management: Best Practices, dkg had two immediate recommendations for improving WoT resilience:

• Regularly refresh your local keyring from the key servers;
• If you have spare space and transit, provide a key server to take part in the pool.

Regular Refreshes This is important because unless keys are refreshed, changed expirations and (more importantly) revocations on keys are never made known to you. Making regular refreshes is easy, though I was surprised to hear people had experienced difficulty with it it s a simple entry to cron, like: 0 0 * * 1 /usr/bin/gpg --refresh-keys to run at midnight on a Sunday, or any other convenient time. Append > /dev/null to make it silent unless there are errors. Provide a key server This is nearly as trivial a refreshing the keyring, but it does take some disk space (on my machine, 4G for the decompressed dump from another server, 7.4G for the database itself and a few hundred MB for other stuff. Supposedly the dump can go after a full database build, but as I m not constrained I haven t bothered). The sks package in Lenny and Squeeze manages the database and answers to clients. However, take care to follow README.Debian carefully, since if the permissions on /var/lib/sks or /var/log/sks aren t set right it will silently fail and much head-scratching will ensue. Building the database for the first time takes some hours even on a reasonably quick machine, and takes a lot of CPU time, so it s probably best done overnight. Once sks is running, it needs to catch up from the date of the key dump to now (which is why a recent dump is always a good start). To do that, it should be listed in the pool.sks-keyservers.net and therefore needs gossip peers. http://code.google.com/p/sks-keyserver/wiki/Peering is an excellent guide, though the version of sks in Lenny does not support multiple listening addresses for either the recon or hkp processes. When a small enough delta between the server and its peers is reached, it s included in the DNS pool for use by other clients.

Having swapped details with many, many people at Debconf, and then been away for a week after that, I found myself with an overflowing mailbox and a long task of open mail, provide pass-phrase, pipe to gpg import . I wanted a way to batch-import all these signatures (there are three times as many, because my key has three UIDs) in one or two goes, and tidy up the stragglers later. David Bremner wrote a small Perl script to do this from an mbox file, but I wanted to work in pure shell and with mutt. Just shoving the mbox at gpg resulted in it decrypting one message, then bailing at the fact the IDEA plugin is not present. Here was my eventual workflow, which only requires you to provide the pass-phrase once:

1. create a maildir, either with maildir-make or a directory with cur, new and tmp directories nested inside;
2. mark all relevant messages as read, and save them to here (it doesn t matter if others get caught up in it);
3. now change to the maildir /cur directory, and run the following bash (disclaimer: totally untested and used at your own risk):
   
for a in ls ; do mv $a $a.gpg; done
gpg --decrypt-files *.gpg
rm *.gpg
gpg --import *
rm *

I expect there are better/quicker/safer ways to do it, but this worked well for me at midnight on a Monday evening. 19/08/10: Yes, it turns out I am a numpty, and Mutt can handle this all by itself with Ctrl-K and a tagged list. This is still quite handy when the private key is not on the machine you re using to read mail, though. Thanks for the corrections.

Since I didn t actually come home from Debconf, but instead took a further week s holiday and lazed around by the beach, I haven t sat down to write anything about it yet. Most importantly, I should say thank you to Joey Hess, Steve McIntyre and Stefano Zacchiroli for arranging the Debconf Newbies programme, without which I would have been stuck at work watching the videos again (though this does have the advantage of seeing three talks at once). Every year I am astounded at the generosity of certain companies who sponsor the conference, since I ve experienced for myself the difficulty of trying to put a corporate price on free software even more so to specifically sponsor newbies, who by definition probably aren t as active in ways that interest sponsors than more established developers. Right up to the day I flew I was nervous (as in any social situation) at meeting so many new people in one go, on my own, and long way from home after all, it s not really easy to back out and go home after that But in fact, everybody I met was warm and friendly, and very supportive in all sorts of ways. I got to see and hear many talks; in the first two days alone:

• Supporting Debian machines for friends and family
• Debian at a large Dutch university
• Why is GNU/Linux Like a Player Piano?
• Bits from the DPL
• Packaging Python modules and applications
• The Unity desktop environment
• Collaboration between Debian and Ubuntu

And of course social events, like Cheese and Wine, Keysigning (handy for putting faces to names), many nights in the third hacklab, a day trip to Coney Island, a privileged viewing of the most nerdy organ in the world, and a trip up the Empire State building: The campus was ideally suited to such a conference, and apart from the mugginess we had excellent weather. I discovered that I rather enjoy watching baseball and that one should repeat the application of sunblock after paddling. But what I enjoyed most of all was being in the same area as so many eminent Debian people, and being so inspired by them to be even more involved technically and socially. I hope to see you all again soon!
<script type="text/javascript"> var flattr_wp_ver = '0.9.11'; var flattr_uid = '32970'; var flattr_url = 'http://www.jwiltshire.org.uk/content'; var flattr_lng = 'en_GB'; var flattr_cat = 'text'; var flattr_tag = 'blog,wordpress,rss,feed'; var flattr_btn = 'large'; var flattr_tle = 'jwiltshire.org.uk'; var flattr_dsc = 'The public face of jwiltshire'; </script> <script src="http://api.flattr.com/button/load.js?v=0.2" type="text/javascript"></script>

and the newbies are ... A long time ago, in a couple of blog posts far far away, we have introduced the DebConf Newbies initiative. I'm hereby happy to announce the actual DebConf newbies and I'm looking forward to meet them at the forthcoming DebConf10 in New York City:

• Jonathan Wiltshire
• Jon Bernard
• Arnaud Fontaine
• Ben Armstrong
• Arthur Loiret
• Serafeim Zanikolas
• Andreas B. Mundt

Now, folks, please be kind with them, they (still) don't know how crazy we can be(come) during DebConf. Above all: do not harm them (too much) at Mao. In exchange, they have already promised that they will fix all RC bugs that will still be open at the beginning of DebConf10 (or maybe I've just read that in their minds, I don't quite remember ...). Does that mean that DebConf10 travel sponsoring is completely OK as of now? No, not really. This initiative was specifically targeting DebConf newbies, but several DebConf "regulars" are planning to attend too. For some of them the amazing DebConf sponsoring team has already found enough resources to secure their travel sponsorship, for quite some others it is not the case yet. This is a pity, because we know from the past that having more Debian folks at DebConf means more hacking, a better distribution, and a better community, ultimately it means a better Debian. Some of the readers of this blog post will be in the condition to improve the situation: it is as simple as donating to Debian or, better, becoming a DebConf10 sponsor by simply mailing the sponsoring team.