I generated 0x94FA372B2DA8B985 (my 4096R GPG key) back in 2008, and revoked my old 1024R v3 key around the same time. However I left my main 1024D key alone, figuring I’d get round to revoking it at some point once the new one was sufficiently trusted. This probably happened some time ago, so today I have finally revoked this key:
pub 1024D/0xF1BD4BE45B430367 1999-10-26 [revoked: 2012-07-13] uid Jonathan McDowell <firstname.lastname@example.org>
If you’re not in the habit of refreshing your GPG keyring regularly now might be a good time to (
gpg --refresh-keys) or at the very least pull my updated key (
gpg --recv-key 0xF1BD4BE45B430367) to make sure you don’t accidentally continue to use it.
(If I haven’t signed your key with my stronger one please do wave a fingerprint/ID at me next time we meet, and ask me for the same in return.)
I’m at DebConf 12 and I’ve decided to use my time to clear out some minor bits and pieces I’ve been planning for a while. One of these was to do some graphing of the Debian keyrings over time. The bzr repository goes back to March 2008, but I’ve also got copies of keyrings for releases back to slink (February 1999). I’ve been a long time user of GD::Graph under Perl, but recently discovered SVG::TT::Graph and have been meaning to play with it. So I did. First up, number of keys in each keyring:
Most of the interesting data is towards the right, but we can also see the point where our v4 keyring overtook v3 keys back in 2001. More recently there’s the end of our v3 support in 2010, and the steady increase of Debian Maintainers. The tiny green line is the Debian non-upload keyring.
Next I looked at key size (limiting myself to the DDv4 keyring to make things simpler):
Here we can see the steady increase of 4096 bit keys since 2009, and to a lesser extent 2048 bit keys. There are a few other sizes - 1 10k key, 1 8k key and 2 3k keys (I suspect these are tied to OpenPGPv2 cards). We’re up to 28% of the keyring being stronger keys, but there’s still a long way to go. (Interestingly the Debian Maintainer keyring is much better with 65% of keys being 2k or larger. The non-upload keyring is all 2k or greater.)
Finally I graphed key type, again limiting myself to the DDv4 keyring:
No real surprises here; DSA far and away the most common with RSA usage increasing as part of the move to larger key sizes. In the past we had a few Elgamal signing keys, but these were shown to be compromised thus disappeared entirely.
What do these graphs show me? At least the following:
- Debian has a steady rate of growth, for both DDs and DMs. As Zack mentioned in his keynote yesterday it would be nice to see more non-packaging contributors.
- We’ve made a noticeable effort towards transitioning to stronger keys, but there’s still a lot of people who need to make the switch.
- Our rate of growth has slowed over the years (not really surprising).
(You should be able to click on the graphs for larger version.)
Multiarch has been coming RSN for an extremely lengthy meaning of the word “soon”. I remember watching Tollef give a presentation about it at DebConf4 and I’m pretty sure it’s been talked about at every DebConf since then as well. Deemed the “correct” answer to the issue of running i386 binaries on x86_64 machines, or old ARM ABI programs on more modern hardware, it’s always seemed to be at least another Debian release away.
Not so anymore. Through foolishness I ended up buying a Brother HL3040CN when I first moved to the US. It was a cheap networked laser printer and it touted Linux support. Quality wise it’s been fine. I don’t use it a lot, but unlike an inkjet I don’t have to worry about not using it for a month and then needing to print something in a hurry and having to clean print heads etc. Where it falls down is that I failed to check that “Linux support” involved source. No. Instead it involves an i386 binary (at least packaged as a .deb, but in a horrible fashion). Up until now I’ve mostly been printing from my laptop, so all the drivers are installed there. I’ve got some guests this week and they needed to print their boarding passes, so I decided it was time to make the house server act as a print server too. It’s an AMD64 box and before now I haven’t had any need to run i386 code on it, so when I installed the driver deb it failed to work. Normally I’d just install
ia32-libs, but this time I decided to try multiarch. So I did:
# dpkg --add-architecture i386 # apt-get update # apt-get install libc6:i386
and magically I was now able to run the printer driver binary. I know there’s a lot more work still to be done (I need to check if I can ditch
ia32-libs on my laptop which runs a few more i386 only apps), but this is pretty cool - thanks to all those involved in making it happen!
Update: I tried to install all the multiarch bits required for Skype on my laptop but hit an issue with
libqtgui4:i386 which ends up pulling in
liblcms1:i386 which isn’t yet multiarch enabled. There was already a bug, #637732 filed by vorlon, and mhy did the appropriate NMU a week ago, so it should hopefully hit testing in the next week. Thanks guys.
I’d just like to say sorry to any of the GNOME people who felt unappreciated; I know you work hard to try and produce a useful user experience out of the box. I ended up doing the dist-upgrade on my work laptop only a week or so after my home machine, and in the process discovered that the nouveau Mesa driver now supports my machine pretty well. It’s taken me a while to get used to it, but my frustrations with the change have diminished and I haven’t felt the need to move to something different. So, a belated thanks for all your hard work.
Meant to post this a while ago when I booked the tickets, but life has a habit of being busy at present. I’m pleased to say I’m going to DebConf 12 in Managua. In the off-chance someone else might be on some of the same flights as me, here’s what I’ve booked:
2012-07-07 00:15 SFO -> 08:12 CLT US466 2012-07-07 11:40 CLT -> 13:44 MIA US1831 2012-07-07 16:07 MIA -> 16:45 MGA US4925
2012-07-14 21:15 MGA -> 01:50 MIA US4944 2012-07-15 06:15 MIA -> 08:19 CLT US1800 2012-07-15 09:40 CLT -> 12:08 SFO US1485
There were some single stop options but the timings didn’t them any quicker, they weren’t any cheaper, and these times worked better for me anyway.
subscribe via RSS