Breaking the Web of Trust

May 13, 2009 / 0 comments

With all the discussion about SHA-1 weaknesses and generation of new OpenPGP keys going on there's some concern about how the web of trust will be affected. I'm particularly interested in the impact on Debian; while it's possible to add new keys and keep the old ones around that hasn't worked so well for us with the migration away from PGPv3 keys. We still have 125 v3 keys left, many of them for users who also have a v4 key but haven't asked for the v3 key to be removed or responded to my email prodding them about it. I don't want to repeat that.

So if we're looking at key replacement we need to have some idea about where our Web of Trust currently stands, and what effect various changes might have on it. I managed to find the keyrings Debian shipped all the way back to slink and ran the keyanalyze and cwot stats against them. I then took the current keyring, pull in all the updates for the keys in it (so that any signatures from newly generated keys would be included) and ran the stats again. Finally I took details of 12 key migrations (mostly from Debian Planet but also a couple of others I knew about) and calculated what the effect of removing each key would be. These stats are cumulative and I replaced the most well connected (by centrality) keys first.

The results are below.

  • Total is the total number of keys in the keyring
  • SCS is the largest Strongly Connected Subset
  • Reachable is the largest reachable subset
  • MSD is the Mean Shortest Distance
  • Centrality is the average centrality for the reachable subset
  • update-foo indicates that foo's key was replaced with a newer one
1999-02-06 (slink)22836(15.78%)50 (21.92%)2.9022
2000-01-03 (potato)375104 (27.73%)180 (48.00%)4.3382
2001-09-22 (woody)948538 (56.75%)704 (74.26%)4.73202008.6249
2005-05-28 (sarge/etch) 1106883 (79.83%)969 (87.61%)3.34852074.6604
2007-12-0411911001 (84.04%)1062 (89.16%)3.11032113.3747
2009-01-18 (lenny)1126947 (84.10%)1010 (89.69%)3.04891941.2594
2009-04-04 (squeeze/sid)1121946 (84.38%)1008 (89.91%)3.04661936.9761
2009-05-06 (current)1067894 (83.78%)958 (89.78%)2.96701759.4363
base1067904 (84.72%)959 (89.87%)2.96401776.4389
update-93sam1067902 (84.53%) 958 (89.78%)2.97341780.9874
update-joerg1067900 (84.34%) 958 (89.78%)2.97761780.7578
update-aurel321067898 (84.16%) 957 (89.69%)2.98031779.2497
update-noodles1067896 (83.97%) 956 (89.59%)2.98311777.8326
update-jaldhar1067896 (83.97%) 955 (89.50%)2.98551779.9193
update-srivasta1067896 (83.97%) 955 (89.50%)2.99041784.3382
update-ana1067895 (83.88%) 954 (89.40%)2.99261784.3102
update-nobse1067893 (83.69%) 953 (89.31%)2.99471782.2392
update-neilm1067892 (83.59%) 951 (89.12%)2.99741782.6098
update-reg1067891 (83.50%) 950 (89.03%)2.99771780.8515
update-rmayorga1067890 (83.41%) 949 (88.94%)2.99841779.4910
update-evgeni1067889 (83.31%) 948 (88.84%)2.99741776.6445

This is actually more hopeful than I thought. There's an obvious weakening as a result of the migrations, but the MSD stays under 3 and the centrality stays fairly constant too. The reachable/SCS counts do decrease, but at this point it looks fairly linear rather than an instant partition. Of course the more keys that are removed the more likely this is to drop off suddenly. Counteracting that DebConf9 is coming up which will provide a good opportunity for normally geographically disperse groups to cross sign, reinforcing the WoT for these new keys.

Either way I at least have a better handle on the current state of play, which gives me something to work with when thinking about how to proceed. For now, bed.

Adventures with an Intel G41 and KMS

Apr 12, 2009 / 0 comments

I bought a new machine recently; for the flat at present with the aim of it becoming an upgrade for the media box once my lease is up. Nothing spectacular; E5200 Dual Core Pentium at 2.5Ghz, MSI G41M-FIDP mobo and 4G of OCZ DDR2 800. I don't need that much, but for £30 how could I resist? Total price, including the extra postage tax to NI and a small case, £200 from eBuyer. I had an existing HD I could use and also managed to find a spare DVD writer too.

I did a 64 bit lenny install from the multiarch netinst CD. There was a slight issue with partman getting confused at one point but I couldn't reproduce it so it might well have been user error. Network, graphics, sound all detected fine out of the box.

Anyway. Part of the reason for a G41 based board is that it's a fairly recent Intel chipset but slightly cheaper than the cutting edge G45. And Intel have been pretty good about getting decent support for their chipsets, both in X for 2D and Mesa for 3D. Unfortunately the X support in lenny isn't great; the driver (2.3.2) works, but I found I needed to disable acceleration for it to be reliable. And I wanted to take advantage of what the chipset could offer.

Helpfully there was a push of various shiny new bits of X into unstable last week, including libdrm 2.4.5 and xserver-xorg-video-intel 2.6.3. So I thought I'd give that a try. I don't want to track unstable on this box as it'll have pretty dire connectivity (Orange 3G at best). Testing may be a possibility but I'd need to sort out a way of pulling the updates via a USB stick on a better connected box - pretty sure I've seen things about doing this in the past so will have to investigate. For the moment I added an entry for unstable, set pinning to prefer lenny and told aptitude to install xserver-xorg-video-intel and mesa from unstable. While I can't possibly recommend this unless you're confident about being able to repair any resulting mess yourself I found it went quite smoothly and didn't pull in nearly as much new stuff as I feared.

The newer X/Mesa packages alone weren't enough. The PCI IDs for the G41 aren't yet in mainline kernels, let alone the 2.6.26 variant in stable. So I compiled up with this patch and figured I'd enable Kernel Mode Setting at the same time. 2 reboots later (when setting KMS you don't want to enable the intelfb driver, but you do still need to enable the "Console on Framebuffer" option. Ooops.) and I had a shiny X install proclaiming OpenGL 2 hardware acceleration support and Xv. Plus switching between X and a text console was pretty damn smooth. Rockin'

On the whole I'm quite impressed, though I am seeing occasional freezes with Xine and Xv output - not sure what it's tickling as mplayer seems to be ok and I can't actually get any error output when it happens. Will try and hook it up to the network and see if I can still login that way at some point. For the moment it's still perfectly usable aside from that.

Oh yeah, we released, didn't we?

Mar 11, 2009 / 0 comments

Nearly a month has elapsed since Debian released Lenny. The interesting thing for me about this release was that I failed to get to the point where running etch was causing me pain. This became even more evident when Katherine commented on my Lenny T-Shirt - I'd forgotten to mention our release to her! Previously there have been a bunch of features coming that I really wanted, sometimes to the point of using backports. It's probably something to do with the way I run Debian; I use stable for remote machines and while in the past this would have meant quite a few work boxes these days it's just a box at my parents' and my colo.

Where I felt the pain during this release cycle was on the boxes where I run unstable (my home desktop) or testing (my work box and my laptops). Development on new shininess slows down significantly while we're preparing for release (not unsurprisingly). And there are things coming up I quite like the look of, largely aimed at the desktop arena. I've been running Network Manager 0.7 from experimental on my EEE, for example - I need the HSO 3G support to avoid unnecessary faff on a daily basis. I've got ATI cards in my work and home desktops, so I'm watching the Mesa developments with interest - roll on OpenGL 2.0 support hopefully. The Intel KMS support that doesn't seem to be quite there yet but RSN, no, really, will be nice for my laptops. Experimental VDRs are looking interesting and perhaps worth upgrading my PVR to.

For a long time I haven't really understood the point of view that Debian shouldn't release. Or rather, I haven't understood why people would think that was a serious option. The first Debian box I installed went into a colo facility shortly afterwards. This is the first release I've not been running Debian on a commercial colo box and while I treat my personal colo in a similar fashion it's not quite the same in terms of priorities. However I still think regular releases are hugely important to the project. Some pain for those of us more interested in new shiny is a small price to pay for producing a flexible, reliable distribution, be they server administrators (though I see a worrying number of people decide to install testing on their production servers and then rarely/never update it), derivers or appliance vendors.

Mind you, now we've released I'm going to have to do all those things I've been putting off. I should probably start with moving my Perl bits into pkg-perl. And maybe I should switch over some sources.list files to point at squeeze instead of lenny...

Bachelor Pad

Mar 10, 2009 / 0 comments

Translink are breaking the trains for 3 months at the end of March. This is manifesting as the line between Ballymena and Coleraine being entirely shut (it's only single track, so it's not like they can do one side at a time), but will hopefully result in a smoother, faster journey. Not much good for the 3 months when my journey goes from a single train ride to a train, bus, then another train ride. And gets longer by 20-30 minutes (so potentially 5 hours a day commuting. Yay!). I think not.

So I have rented a flat in Belfast, conveniently only 3 minutes walk from work. 3 month leases are hard to find so I have it for 6 months. I'm a bit freaked. I shouldn't be really; I lived alone when Katherine first moved back to NI. But that was in a house I'd been in for ages rather than somewhere entirely new to me. It proved its worth last night when we were able to walk to Do You Remember the First Time? in a couple of minutes though. Being in the city centre is damn handy, though I'm having to get used to the regular noise of traffic again. :)

(This post primarily a test of Drivel; it's not worth the hassle of dealing with Virgin or BT to get a broadband connection, so I'm going to end up continuing to use my Orange 3G dongle and trying to do things in local clients where possible.)

Recording application sound output with ALSA

Feb 24, 2009 / 0 comments

I wanted to record a conference call for a colleague who couldn't make it. Normally I'd cheat and run Wireshark to capture and dump an unencrypted VOIP stream, but for various reasons that wasn't an easy option and Skype was going to work better for the call. But how to record it? IRC suggested various ALSA magic options, which looked like they'd do the trick if I could only understand the fine manual. It actually turned out to be much easier than it looked. I dropped:

pcm.fileout {
	type file;
	slave {
		pcm "hw:0"
	file "/home/noodles/pcmout";
	format "raw";

into .asoundrc, restarted Skype and told it to use the fileout device for audio out. That led to a pcmout file being created, as well as the sound going to the sound card.

sox -r 44100 -s -2 -c 2 -t raw pcmout -t wav foo.wav then converted that file into a WAV that could be played back. For some reason setting format to wav in the ALSA config resulted in an error - throwing sox at the problem was the easy answer but I suspect that step could be eliminated with some more doc reading.

subscribe via RSS