There are certain people who are NIH-prone. Usually I consider this insane, but sometimes I sympathize. Certainly I have pulled a NIH once or thrice before. Maybe I'm one of those old curmudgeons who incorrectly remembers the past, but I have the feeling that software used to work a whole lot better. Admittedly it did less, but it was also less prone to weird semi-failures. I am probably repressing a bunch of kernel oopses in the '90s. Now though, I can waste a week and a half being miserable as SIP clients fail on me erratically, because I hate Twinkle and no one thought to tell me that Twinkle is really the only SIP client that works. The interoperability of CalDAV and GroupDAV servers and clients seems to be abysmal. The same even appears to be true of plain ol' WebDAV. There are multiple forks of Markdown. I blame John Gruber for not maintaining a strong-enough central standard. No working LUKS-encrypted live images appear to exist in the wild. The only reliable and useful backup software for my needs was abandoned in 2008. Everything in Rails is bloated and crazy, except for Redmine. How is Redmine able to transcend? I do not understand. There is no way you can run an Android phone on only free software. freeswitch is on crack.

Luke: It's great to see open code for the 6410, but I'm pretty sure that that chip uses Samsung's own GPU design rather than being anything PowerVR based. What makes you think it's an SGX? The listing here implies that it's an unrelated part.

Let's say you set up a machine using an encrypted disk with LUKS (debian-installer's partman makes this wonderfully easy!). You choose an initial passphrase, get the machine working, and it's working great. Then, you need to restart it, and realize that (for whatever reason) you've forgotten or lost the passphrase for the volume. oops! (i'm sure this has never happened to you -- let's just pretend it's your less-fortunate friend). If your system is still running, and you have superuser access to it, you can actually set a new passphrase for the LUKS volume using information that the dm-crypt kernel module has about the in-use mapping. In my examples, i'll imagine that the source volume is /dev/XXX2 and the exported cleartext volume is known by the device-mapper as XXX2_crypt In the bigger picture, this should serve as a reminder that even though your disk is encrypted, if someone gets live access to the superuser account on a system with the encryption keys loaded, your data is no longer secret. Before you do any tweaking, you might want to back up your LUKS header, just in case:

0 root@example:~# umask 077
0 root@example:~# cryptsetup luksHeaderBackup /dev/XXX2 --header-backup-file XXX2.luksheader.backup
0 root@example:~# 

Maybe also copy that off the machine, since a copy of the LUKS header stored within its own volume isn't terribly useful for a backup-recovery situation. You might also be interested in looking at the contents of the LUKS header:

0 root@example:~# cryptsetup luksDump /dev/XXX2
LUKS header information for /dev/XXX2
Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	2056
MK bits:       	256
MK digest:      93 51 6c 66 ec ce 32 54 6f 6b 52 d1 27 9b 5a 62 6f 6b 52 d1
MK salt:       	b2 ca 20 49 9f 78 49 c2 fe 15 b4 0f 74 11 23 49
               	64 9e 61 bb f2 82 60 47 a5 76 fa a4 24 0e 5a 7e
MK iterations: 	10
UUID:          	052f1da0-21a1-11e0-ac64-0800200c9a66
Key Slot 0: ENABLED
	Iterations:         	218733
	Salt:               	f2 ae 8c 53 48 a5 f0 bf e1 2c 06 5f 5a bd ff d9
	                      	9a 2e d1 49 3a 63 f8 49 82 ed ae 86 7b 7b 7e 76 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
0 root@example:~# 

Now, the fix: We pull the live "master key" from the running device map, and fill a new luksKeySlot from it (this example uses bash's <() syntax for process substitution -- if you use a different shell, i'm sure you can find a different way to do it):

0 root@example:~# cryptsetup --master-key-file <( 
> dmsetup --showkeys table   awk '/^XXX2_crypt: /  print $6  '   tr -d '\n'   perl -e 'print pack("H*", <STDIN>);' 
> ) luksAddKey /dev/XXX2
Enter new passphrase for key slot: abc123
Verify passphrase: abc123
2 root@example:~# 

(note that the luksAddKey invocation above returned an error code of 2 even though it succeeded. I think this is a bug in cryptsetup's return code, not a bug in the password resetting -- it should have returned 0 instead of 2). You can check to see that a new key slot was enabled by re-running cryptsetup luksDump And if you really want to double-check before you reboot, you can try enabling a third keyslot using the passphrase you just added, since this would not succeed if your new passphrase failed to unlock any of the existing keyslots:

0 root@example:~# cryptsetup luksAddKey /dev/XXX2
Enter any passphrase: abc123
Enter new passphrase for key slot: anotherpassphrase
Verify passphrase: anotherpassphrase
0 root@example:~# 

You can also get rid of the original keyslot (which you don't know the passphrase to) like this:

0 root@example:~# cryptsetup luksKillSlot /dev/XXX2 0
Enter any remaining LUKS passphrase: abc123
0 root@example:~# 

(the above commands were all demonstrated using debian testing, with cryptsetup 2:1.1.3-4 and dmsetup 2:1.02.48-4) Tags: cryptsetup, dmsetup, luks, tip

On a lark, I signed up for the pilot program of the Google Cr-48 about a week ago. To my surprise, I found the distinctive box on my doorstep a week later. After initially mistaking it for an overpacked, late-model OLPC XO-1 I would have to repair, I sort of did a double-take as I realized what I had received. Using Chrome OS Wow, they weren t kidding about the boot time. Chrome OS responds (to suspend / resume and boot / power-off) very quickly. Responsiveness elsewhere in the OS of course varies on system load and other factors. On the terms page, there is a system security setting which tells me I have a Trusted Platform Module, and that my TPM has a randomly generated password. The dialog could use some rewording; I m pretty familiar with the idea of a TPM, but I m still not sure what I m to do with that information. Cloud print is really a problem for me, right now. I use school printers for the majority of my work, which I was previously able to use by adding them by IP address. Unless there s some magic I m missing here, I can t do that with Chrome OS, and such a feature will not be supported. (except by connectors on Windows and Mac computers) General thoughts I can t imagine using a system running Chrome OS as a primary computer. The biggest missing feature is PGP (or any sort of encryption) support for email. This is probably not terribly difficult to implement as an extension, but the idea of my cryptographic software being automatically updated is rather unsettling. I think I ll have to agree with Paul Buchheit that ChromeOS will have to merge with Android; there is a utility for local apps, even if they re becoming less and less critical.

Mehdi is a Debian developer for a bit more than a year, and he s already part of the Debian Release Team. His story is quite typical in that he started there by trying to help while observing the team do its work. That s a recurrent pattern for people who get co-opted in free software teams. Read on for more info about the release team, and Mehdi s opinion on many topics. My questions are in bold, the rest is by Mehdi (except for the additional information that I inserted in italics). Who are you? I m 27 years old. I grew up in Ariana in northern Tunisia, but have been living in Paris, France, since 2002. I m a PhD Student at the PPS laboratory where I study synchronous concurrent process calculi. I became interested in Debian when I saw one of my colleagues, Samuel Mimram (first sponsor and advocate) trying to resolve #440469, which is a bug reported against a program I wrote. We have never been able to resolve it but my intent to contribute was born there. Since then, I started to maintain some packages and help where I can. What s your biggest achievement within Debian? I don t think I had time to accomplish a lot yet I ve been mostly active in the OCaml team where we designed a tool to compute automatically the dependencies between OCaml packages, called dh-ocaml. This was a joint work with St phane Glondu, Sylvain Le Gall and Stefano Zacchiroli. I really appreciated the time spent with them while developing dh-ocaml. Some of the bits included in dh-ocaml have been included upstream in their latest release. I ve also tried to give a second life to the Buildd Status Pages because they were (kind of) abandoned. I intend to keep them alive and add new features to them. If you had a wand and could change one thing in Debian, what would that be? Make OCaml part of a default Debian installation But, since I m not a magician yet, I d stick to more realistic plans:

1. A lot of desktop users fear Debian. I think that the Desktop installation offered by Debian today is very user-friendly and we should be able to attract more and more desktop users. Still, there is some work to be done in various places to make it even more attractive. The idea is trying to enhance the usability and integration of various tools together. Each fix could be easy or trivial but the final result would be an improved Desktop experience for our users. Our packaged software run well. So, each person can participate since the most difficult part is to find the broken scenarios. Fixes could be found together with maintainers, upstream or other interested people.
   
   I ll try to come up with a plan, a list of things that need polishing or fixes and gather a group of people to work on it. I d definitely be interested in participating in such a project and I hope that I ll find other people to help. If the plan is clear enough and has well described objectives and criteria, it could be proposed to the Release Team to consider it as a Release Goal for Wheezy.
   
   
2. NMUs are a great way to make things move forward. But, sometimes, an NMU could break things or have some undesirable effects. For now, NMUers have to manually track the package s status for some time to be sure that everything is alright. It could be a good idea to be auto-subscribed to the bugs notifications of NMUed packages for some period of time (let s say for a month) to be aware of any new issues and try to fix them. NMUing a package is not just applying a patch and hitting enter after dput. It s also about making sure that the changes are correct and that no regressions have been introduced, etc
   
   
3. Orphaned packages: It could be considered as too strict and not desired, but what about not keeping orphaned and buggy packages in Testing? What about removing them from the archive if they are buggy and still unmaintained for some period? Our ftp archive is growing. It could make sense to do some (more strict) housekeeping. I believe that this question can be raised during the next QA meeting. We should think about what we want to do with those packages before they rot in the archive.

[Raphael Hertzog: I would like to point out that pts-subscribe provided by devscripts makes it easy to temporarily subscribe to bug notifications after an Non-Maintainer Upload (NMU).] You re a Debian developer since August 2009 and you re already an assistant within the Release Management team. How did that happen and what is this about? In the OCaml team, we have to start a transition each time we upload a new version of the OCaml compiler (actually, for each package). So, some coordination with the Release Team is needed to make the transition happen. When we are ready to upload a new version of the compiler, we ask the Release Team for permission and wait for their ack. Sometimes, their reply is fast (e.g. if their is no conflicting transition running), but it s not always the case. While waiting for an ack, I used to check what was happening on debian-release@l.d.o. It made me more and more interested in the activities of the Release Team. Then (before getting my Debian account), I had the chance to participate in DebConf9 where I met Luk and Phil. It was a good occasion to see more about the tools used by the Release Team. During April 2010, I had some spare time and was able to implement a little tool called Jamie to inspect the relations between transitions. It helps us to quickly see which transitions can run in parallel, or what should wait. And one day (in May 2010, IIRC), I got offered by Adam to join the team. As members of the Release Team, we have multiple areas to work on:

1. Taking care of transitions during the development cycle, which means making sure that some set of packages are correctly (re-)built or fixed against a specific (to each transition) set of packages, and finding a way to tell Britney that those packages can migrate and it would be great if she also shared the same opinion. [Raphael Hertzog: britney is the name of the software that controls the content of the Testing distribution.]
2. Paying attention to what is happening in the archive (uploads, reported RC bugs, etc ). The idea is to try to detect unexpected transitions, blocked packages, make sure that RC bug fixes reach Testing in a reasonable period of time, etc
3. During a freeze, making sure that unblock requests and freeze exceptions are not forgotten and try to make the RC bug count decrease.

There are other tasks that I ll let you discover by joining the game. Deciding what goes (or not) in the next stable release is a big responsibility and can be incredibly difficult at times. You have to make judgement calls all the time. What are your own criteria? That s a very hard to answer question (at least, for me). It really depends on the case . I try to follow the criteria that we publish in each release update. Sometimes, an unblock request doesn t match those criteria and we have to decide what to accept from the set of proposed changes. Generally, new features and non-fixes (read new upstream versions) changes are not the kind of changes that we would accept during the freeze. Some of them could be accepted if they are not intrusive, easy and well defended. When, I m not sure I try to ask other members of the Release Team to see if they share my opinion or if I missed something important during the review. The key point is to have a clear idea on what s the benefit of the proposed update, and compare it to the current situation. For example, accepting a new upstream release (even if it fixes some critical bugs) is taking a risk to break other features and that s why we (usually) ask for a backported fix. It s also worth noticing that (most of the time) we don t decide what goes in, but (more specifically) what version of a given package goes in and try to give to the contributors an idea on what kind of changes are acceptable during the freeze. There are some exceptions though. Most of them are to fix a critical package or feature. Do you have plans to improve the release process for Debian Wheezy? We do have plans to improve every bit in Debian. Wheezy will be the best release ever. We just don t know the details yet During our last meeting in Paris last October, the Release Team agreed to organize a meeting after Squeeze s release to discuss (among other questions) Wheezy s cycle. But the details of the meeting are not fixed yet (we still have plenty of time to organize it and other more important tasks to care about). We would like to be able to announce a clear roadmap for Wheezy and enhance our communication with the rest of the project. We certainly want to avoid what happened for Squeeze. Making things a bit more predictable for developers is one of our goals. Do you think the Constantly Usable Testing project will help? The original idea by Joey Hess is great because it allows d-i developers to work with a stable version of the archive. It allows them to focus on the new features they want to implement or the parts they want to fix (AIUI). It also allows to have constantly available and working installation images. Then, there is the idea of having a constantly usable Testing for users. The idea seems nice. People tend to like the idea behind CUT because they miss some software disappearing from Testing and because of the long delays for security fixes to reach Testing. If the Release Team has decided to remove a package from Testing, I think that there must be a reason for that. It either means that the software is broken, has unfixed security holes or was asked for the removal by its maintainer. I think that we should better try to spend some time to fix those packages, instead of throwing a broken version in a new suite. It could be argued that one could add experimental s version in CUT (or sid s) but every user is free to cherry-pick packages from the relevant suite when needed while still following Testing as a default branch. Besides, it s quite easy to see what was removed recently by checking the archive of debian-testing-changes or by querying UDD. IMO, It would be more useful to provide a better interface of that archive for our users. We could even imagine a program that alerts the user about installed software that got recently removed from Testing, to keep the user constantly aware any issue that could affect his machine. About the security or important updates, one has to recall the existence of Testing-security and testing-proposed-updates that are used specifically to let fixes reach Testing as soon as possible when it s not possible to go through Unstable. I m sure that the security team would appreciate some help to deal with security updates for Testing. We also have ways to speed migrate packages from Unstable to Testing. I have to admit that I m not convinced yet by the benefits brought by CUT for our users.

---

Thank you to Mehdi for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

I ve been thinking a lot recently about information security and passwords. It s widely agreed that two-factor authentication, which combines something-you-know (a password) with something you have (eg. a smart card or some one-time-password) is superior to using a password by itself. Most solutions I ve seen, short of client-side certificates, both require a trusted third party and provide little auditability. I m working on a project which attempts to address those problems. Basically, the idea is that you attempt to perform an action on a website, like logging in, moving some money between accounts, or restarting a cluster. Then, your mobile device¹ (Android, iPhone, or some custom hardware) starts buzzing, displaying the text of the action. When you approve or deny the action, your device uses a locally stored private key to sign the text of the approval and send it back to the server. The server checks that you approved the same transaction number and text, then allows the action. The server can store the approval notice to allow auditors later to determine that somebody in possession of the private key signed the action request. So far, I ve written a small Django server application, and a Python CLI device and client. They re not yet ready for a public release; I need to write up installation instructions and test it a bit more, but I ll publish them soon on Launchpad. On the usability side of things, I plan to conduct some trials in January comparing it to things like Google Authenticator. This should be less susceptible to MITM attacks than one-time-passwords, since you can authenticate specific transactions, rather than entire sessions. On the other hand, I m no security researcher. Dear lazyweb, are there any problems with the above approach? Also, if I m going to release this (as I plan to once I get something working), I need a name. Ideas?

1. iPhone used in the graphic to the right because a SVG was handy. Image adapted from work by Virgile Pypaert [CC-BY-SA-3.0], via Wikimedia Commons

DebConf 11 will take place from July 24 to 30, 2011, in the city of Banja Luka, Republika Srpska, Bosnia and Herzegovina.

The final calendar of the event is:

• July 17, 2011: Setup day (only for people doing initial setup)
• July 18-23, 2011: DebCamp, the yearly developer work sessions.
• July 23, 2011: Arrival Day for DebConf11
• July 24-30, 2011: DebConf11
• July 31, 2011: Departure/cleanup day

The call for papers and registration dates are still to be decided.

More information at the DebConf 11 website.

At the end of September, things were quite exciting as we had our first project meeting. At that meeting those in the room saw a demonstration of the Moonshot GSS EAP mechanism and we discussed a number of open issues and began to plan for our test infrastructure. We ve made significant progress on the specification front and on explaining Moonshot to important communities since then. However there has been little public progress on the implementation front. Unfortunately, getting the necessary legal clearance and agreements to release code often takes longer than anyone would like; that is what is happening here. We re all eagerly awaiting final approval from the lawyers and JANET(UK) management. However, things have been moving behind the scenes. Throughout much of October, Luke Howard and Linus Nordberg were working on their respective parts of the code. I ve also been working on putting together the test and build infrastructure. As we discussed at the meeting, we re going to use Debian and Ubuntu as the basis for our testing. For example, we hope to release virtual machine images for these platforms for the major Moonshot components. Thus the primary build environment for our testing and virtualization will be for Debian. I ve been putting together that here. Right now, that branch will pull together packages of the SAML infrastructure that we need. I ve also been looking into virtualized test frameworks and believe I ve found one that meets our needs. I ve also put together some primitive build infrastructure that is independent of packaging available here. I ve set up a buildbot that builds both environments. So, as the code becomes available we ll be in a good position to start making it available.

Even though we had approximate dates from very start, I would like to announce official dates when DebConf11 will be held in Banja Luka, Bosnia and Herzegovina.


DebCamp: 25th 31st July 2011 DebConf: 1st - 7th August 2011
We encourage you to arrive one day earlier (24th July for DebCamp, and 31st July for DebConf), final departure date will be 8th August.
Vacation, it s in our plans to talk to travel agencies, so for those who wanted vacation after DebConf11 as its participants can enjoy shores of Bosnia, Croatia, Montenegro and Greece by discount prices. We re already looking forward your stay on Balkans! Adnan


http://wiki.debconf.org/wiki/DebConf11/BanjaLuka

Last week I was on my first Ubuntu Developer Summit (UDS-N), I wanted to attended this summit for couple of reasons: 1. Developer, I m part of Debian Java, working on Eclipse IDE, and as you re developing Debian, you re automatically developing Ubuntu, no? 2. DebConf11 main organizer, I really wanted to see how it s all done on corporate level, for instance we re going with hotels instead of student dorms and so on. 3. Migration to Linux infrastructure, make contacts and have some talks on this topic, because after DebConf11 in Bosnia a lot of institution will most probably open doors to open solutions such as Linux. I went to this summit without any expectations or plans, just said I ll play it by ear. This years UDS was held in Orlando, Florida before Orlando I was planning to stay in NYC for couple of days, therefor my whole plan was to get to NYC, then Orlando then head back home I NYC I spent couple of days here with my cousins and friends, as always NYC never fails to surprise me, and I ll always stop by even if it s only for couple of days I wanted to meet up with couple of Debian people as well, but unfortunately my schedule was too tight so Caribe Royale, Orlando Please note that this whole trip was crazy (in a good way) starting from Sarajevo; on my flight from NYC to Orlando I see a guy that s sitting in front of me is wearing Canonical Landscape tshirt, I approach him and it turns he was Jamu Kakar working on Landscape. Since my luggage was late we had conversations from Debian over Ubuntu to Java to everything pretty much. While we were still at the airport, we bump into two more people going to UDS. As we got to hotel, same moment we walked out of cab there he was Jorge Castro, was he there just to smoke a cigarette or whatever doesn t even matter, what matters is that even before walking into hotel building I knew where reception, my tower and bar was, everything I needed to know at that moment Hotel where everything was held was Caribe Royale and even though I looked at their website I thought there was no way it s all going to be that nice, to my delight it was exact replica. Place is All-Suite Hotel and Convention Center , which meant that both accomodation, venue and everything else was in one place which is 15 minutes later after I checked in, I was at a bar talking to Jim Baker about Java, Jython and Python, exact things I wanted to talk about at that given moment. What I said in these last couple of paragraphs sounds pretty cool eh? Well to me this whole UDS was just like this, everybody was so accessible and open for discussion, from Jono Bacon walking around offering candy to UDS reception staff Michelle, Marianna and others who were always there whether you had a complaint, problem or a praise. I really should stop mentioning names, because I ll forget somebody, and since it s just not fair because I had a feeling everybody was just there for you, whatever it was you needed. Ubuntu Developer Summit (UDS-N) Ubuntu, Debian, DebConf, differences? Even though I said I ll play it by ear, from very beginning I thought I d be complete outsider, being part of Debian and all. Quite contrary, I was everything but outsider, and even more there was plenty of Debian people there, including current DPL Stefano Zacchiroli, Colin Watson, Riku Voipio just to name few. There was also a Debian Healt Check plenary. But overall, there are differences between DebConf and UDS. One of the things is that you can attend UDS remotely I m not sure how much is this doable on DebConf, but then again vast differences are that UDS is filled with BOF s (as we would call it in Debian) meetings of different teams, I attended a lot of these, and most of them end with some kind of conclusion. While each day there was (only?) an hour of lectures on various topics, which on DebConf we would characterize maybe even as speed talks . However, everything was high paced, and it all ended up on You think that s a problem? How do you think we could solve it? . I had a feeling even if I didn t say something out loud that someone would hear me and approach me to discuss it. Everything was straight forward, all in goal to resolve certain issue or a problem, which I absolutely loved. Fun It wasn t all work, even though Orlando doesn t seem to be my kind of city from what I saw, it s way too magical for my taste There was a lot of places where you could go to enjoy yourself. Good people at Canonical even offered me free ticket to Disney World, there was a lot of destinations to visit and transpiration was also organized by Canonical. Unfortunately I missed the notorious UDS party on Friday because I had to head home early, but possibly I ll make it next year Even though, hotel was that great and to be honest you didn t have to leave to look for party. My favorite was Universal City Walk, one night I decided to go to see Blue Man Group, best part of it was that I got pulled up on stage by one of the members and was part of one of the acts! This is definitely something everyone should see during his life, one moment you re laughing like a lunatic, while other moment you re just having goose bumps from the performance itself. Amazing stuff. After all I wrote here along with the pictures, is there even anything else I need to say? I believe that even if I didn t play it by ear, this whole trip would exceed all my expectations in every possible sense. Because that s really what happened, those three reasons I was going to UDS for? Far more happened than that. All I can say in the end is that I ll move closer to having a part in Ubuntu development, and yea, I ll try to be regular on UDS from now on See you in Budapest? If all these photos weren t enough, you can find official group photo as well as personal set of photos can be found on: UDS-N photos by 2010 Sean Sosik-Hamor

At The MIT Kerberos Consortium s 2010 conference, Josh Howlett and Sam Hartman delivered a talk on Moonshot. Slides should be up in a day or so. We reported on status and gave a brief overview. The new material was apropos for the venue. At the bar BOF back in March at IETF 77, we received several comments on Moonshot s limitations. It doesn t work well for services that require rapid authentications for multiple requests. There s not a good story for use when a Moonshot service needs to contact another service. There isn t a good standardized mechanism for mapping in domain-specific policy. We presented a proposal that Luke and Sam developed to optionally provide a Kerberos ticket as part of moonshot authentication. This scales from a service that simply generates its own service tickets all the way through resource domains that have many services and complex policy and provide the client a TGT. Clients can implement the feature in order to achieve better performance. Server can implement the feature in order to get delegation support within a resource domain and to get policy mapping. Luke has prototyped a version of this service involving a service ticket. We plan on briefly mentioning a desire to have extensible fast reauthentication support at the ABFAB meeting in IETF 79. However in the interest of getting the working group off to a good start we re going to focus on the well understand parts of the system and formally propose this extension after IETF 79.

As Christian mentioned, the Debian Keyring Maintainers did a promote this weekend of the new keyring. I figure it s an opportune time to perform a public key transition, since this had the effect of replacing my key on the keyring. For my new key, 0xF9FDD506, I decided to opt for a 4096-bit RSA, which is stronger than I should have to worry about for the foreseeable future. The key is much better connected than my previous one, 0x0AC70206. I also have a transition document, ripped almost word-for-word from Christian s. If you signed my previous key, you should sign the new one unless you re feeling extra paranoid today.

It s often said that KDE and GNOME are too bloated, too complex, too slow, or whatever. I won t deny that these critics are often justified, and some parts of the code are badly designed. But there can also be reasons behind this bloat: they are called features. When you want to mount an encrypted USB disk, you can write your own script and even write your own udev rules so that it can be mounted with autofs. It looks fun to find a way to use software that has been obsolete and useless for 10 years, in a way that requires administrator rights just to add a new model of USB disk to your system, and puts the private key in a place that is readable for anyone stealing the hardware. But while it will turn out as an interesting read for those willing to understand how the device mapper and cryptsetup work, I think it s a bit abusive to present it as a correct implementation of an encrypted disk mounting setup. Discover gnome-disk-utility In etch, GNOME shipped with pmount, a nice utility, still included in Debian, that allows to mount your keys, encrypted or not. In lenny, it shipped with HAL, and allowed to store LUKS passphrases securely in the GNOME keyring. Whenever you plug a LUKS-encrypted disk on a lenny system running GNOME, it is immediately made accessible, and that s all. In squeeze, things go much farther thanks to udisks (the backend) and gnome-disk-utility (the frontend). Roland rightly pointed out that the g-d-u documentation is nonexistent - it consists only in a screenshot, which is outdated. Nevertheless, you will find it practical if you want to encrypt a USB drive, since you can format it, partition it, create encrypted volumes and the filesystems on them, in a few clicks and without root permissions. If you use nautilus, it will also mount them automatically using the same backend when you plug them. I don t know for you, but I think it is worth a few CPU cycles of my 3GHz processor and a few dozen megabytes of my 500GB drive.

You have a computer. You're afraid of it being stolen by baddies or raided by the police, so you've encrypted its hard disk with LUKS. You also want to carry around some of your crypto keys (SSH and/or GPG), or any kind of sensitive data, on an USB key, so you can restore a normal activity in case the computer gets stolen or becomes untrustworthy. You like things that Just Work, including automounting with autofs (no GUI popups, no need to manually unmount and so on). But of course, you can't very well just mount the drive and store your keys on it in the clear. Well, actually you can (I did it for way too long), but let's assume you want to do without. Because USB keys get stolen or lost, too. autofs just handles the mounting of the drives, not their unlocking, and there's no hook in there specifically for LUKS. There is, however, a more generic way of running arbitrary commands on mounting: the program maps. It's all described in the documentation, so I'll just paste the relevant parts of my /etc/auto.removable, with a few comments. Remember to make it executable and reference it in /etc/auto.master.

 #! /bin/sh
 volume=$1
 autoluks ()  
   dev=/dev/$1
   cryptname=$ 1 _crypt
   cryptdev=/dev/mapper/$cryptname
   keyfile=/etc/private/$cryptname.key
   options=$2
   [ ! -e $dev ] && exit 0
   if [ -b $cryptdev ] && ! cryptsetup status $cryptname   grep -q device:.*$dev ; then
       cryptsetup remove $cryptname   logger
   fi
   cryptsetup --key-file $keyfile luksOpen $dev $cryptname   logger
   [ -b $cryptdev ] && echo $options :$cryptdev   true
  
 case "$volume" in
   # LUKS-encrypted volumes
   lacie-keys)
       autoluks lacie-keys -fstype=ext4,ro,noatime,nodev,noexec,nosuid
       ;;
   lacie-keys-rw)
       autoluks lacie-keys -fstype=ext4
       ;;
   lacie-backups)
       autoluks lacie-backups -fstype=ext4
       ;;
   # Non-encrypted volumes
   cd)
       echo -fstype=iso9660,ro,nodev,nosuid            :/dev/cdrom
       ;;
   floppy)
       echo -fstype=auto,sync,nodev,nosuid             :/dev/fd0
       ;;
 esac

The astute reader will have noticed that the keys volume is mounted either read-only or read-write with the same mechanism. This volume contains SSH keys that I use quite regularly, that filesystem is going to be mounted and unmounted very often. USB keys, and flash memory in general, don't really like repeated writes. Fortunately, the SSH keys are mostly read, and very rarely written to, so I can afford to mount the partition read-only and save the write cycles for when I generate new keys (the mere action of mounting a partition read-write changes it, even if the files in it are never modified). The backups volume is mostly accessed in write mode, and much less frequently anyway, so there's no need for a distinction there. This supposes that the partitions on the USB key appear as /dev/lacie-keys and /dev/lacie-backups. Due to the dynamic naming of devices, you may like to use rules similar to the following in /etc/udev/rules.d/local.

 KERNEL=="sd[a-z]1", ATTRS idProduct =="1027", ATTRS idVendor =="059f", ATTRS manufacturer =="LaCie", ATTRS product =="LaCie iamaKey", SYMLINK+="lacie-keys"
 KERNEL=="sd[a-z]2", ATTRS idProduct =="1027", ATTRS idVendor =="059f", ATTRS manufacturer =="LaCie", ATTRS product =="LaCie iamaKey", SYMLINK+="lacie-backups"

You'll also need to initialize LUKS on the partitions, save the key, make the filesystems, and so on. If you're still with me, you probably know what I'm talking about, then I don't need to explain about that. This setup works for me, but there's no guarantee and so on. Based on a tutorial found on the Debian Administration website (great resource, by the way). Update: I'm told a large part of the script could be replaced with pmount. If you like short scripts, you may want to investigate that too. Update 2: Josselin points out a different solution using Gnome, udisks, gnome-disk-utility and Nautilus. It's worth checking out, for those who like to run all that and click around. I can't test it right now (Gnome/Nautilus currently refuses to mount any USB key, for some presumably transitional reason), but I have no reason to believe it's inherently broken. I just don't like having to do anything when I plug my key or before I unplug it, and I'm not always running a graphical session with a desktop.

The following developers got their Debian accounts in the last 2 months:

• Luke Faraone (lfaraone)

Congratulations!

I use to take my (company) notebook with me on business travels.
Two times I now had the unlucky situation that something bad happened to it on such an occassion. Whenever you get in the situation that you need to reinstall your system in a hotel room you'll might have the same wish that I got: A way to quickly bring the system in a state where I could work with it.

Well, I used FAI a while back for a customer. Its a real great tool for automated installations and I really prefer it over debian-installer preseeding. Apart from the fact that the partitioning is way easier it also gives me the power to complete the whole installation up to a point where I've got almost nothing to do anymore. It also features an installation completely from CD or USB-Stick which makes it suitable for me.

However, my notebook installation has a little "caveat" which made that a little bit more harder as previously thought. As it is a notebook and I carry company data on it it has to be encrypted. Disk encryption at a whole.
The stable FAI version does not support this.
The problem is: The current support for crypto in setup-storage (FAIs disk setup tool) is not very far. Supported is the creating of a LUKS container with a keyfile, saving this keyfile to the FAI $LOGDIR and creating a crypttab.
Unfortunately for a root filesystem this would leave us with an unbootable system, because this requires manual interaction. And on the other hand using a keyfile for a cryptoroot is a no-go anyway. We want a passphrase.
On a side-note: cryptoroot support with a keyfile is more complex than with a passphrase, as you have to provide a script that knows how to get to the key.

So I started experiments with scripts in the FAI-configuration that added a passphrase, changed the crypttab and recreated the crypttab. That worked, although it was very ugly.
But due to a good coorperation with Michael Tautschnig, a FAI- and Debian-Developer, on this, the FAI experimental version 4.0~beta2+experimental18
now supports LUKS-volumes with a passphrase that can be specified in the disk_config.

Now its actually possible to setup a system like mine with FAI out-of-the-box. One thing (apart from the FAI configuration and setup as you want and need it) has to be done, anyway:
The initrd support of cryptsetup requires busybox (otherwise you will see a lot of "command not found" errors and you system won't boot) and it requires initramfs-tools, which is standard nowadays.
So you have to make sure that these packages are in your package config!

So now I can define a FAI-profile for my notebook, create a partial fai mirror with the packages it needs and put all this together on an USB stick with fai-cd (don't worry about the name, it can be used to create ISO images as well). I can carry this with me and if I need it I stick it into my notebook and let FAI automatically reinstall my system. Nice :)

Update: Somebody asked me, weither he understood me right, that I'd put my LUKS passphrase on a FAI usbstick clear-text. Obviously, the answer is and should be NO. What I do and what I'd suggest to others: Use a default passphrase in the FAI configuration, install with it - after all on a fresh installation there is not much to protect - and once it is finished *change* the passphrase to something secure by adding a new keyslot and removing the old.

Richard Darst has been writing about DebConf organisation and wrote about DebCamp. Thought I'd give my story about where the idea for DebCamp came from, for some context. DebConf2 in Toronto was my first DebConf. I had sadly missed DebConf1 due to EPASSPORT despite having sponsored tickets; something I still kick myself about. Things were not as well organised back then. Anyway, since Ottowa Linux Symposium was the week before DebConf, some of us were in Canada early for that, and needed to find something to do in the time between conferences. My thought was, find someplace to camp. It'd be a cheap way to see more of Canada and decompress. I posted this plan to debian-private and Andreas Schuldei and I spent several days canoing around Algonquin park. Of course, we'd never met before. I'd met probably less than five European debian developers before that point. We experienced big scary lakes that challenged our limited canoe skills, portaged and camped, and even saw a moose. Later during DebConf2, I distinctly remember mentioning our camping trip and saying "we could have a DebCamp before the next DebConf". And sure enough, before DebConf3 there was a DebCamp[1]. In the days we hacked on d-i and stuff. We camped out in the gym of a primary school in Oslo, and hung out through the long evenings out front. Some people even brought tents. Since then, DebCamp has developed into the integral warmup for DebConf that Richard describes. I'd rather see it more ad-hoc and scruffy, but you can't argue with the purpose it serves. So, are there any good places to camp near Banja Luka? [1] Even then the DebConf orga team made it seem that easy.

(update: yesterday's version was using http://wiki.debian.org/Teams/ReleaseTeam as reference, while http://www.debian.org/intro/organization is the one that's up-to-date. Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!)...and Martin zobel (who's apparently forgotten on the page). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, luk, HE). Hat off, guys (only guys there, yet another place for d-w to show up).

Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, HE). Hat off....