I recently dug through my history of involvement with TeX (Live), and found out that in January there are a lot of anniversaries I should celebrate: 14 years ago I started building binaries for TeX Live, 11 years ago I proposed the packaging TeX Live for Debian, 10 years ago the TeX Live packages entered Debian. There are other things to celebrate next year (2017), namely the 10 year anniversary of the (not so new anymore) infrastructure in short tlmgr of TeX Live packaging, but this will come later. In this blog post I want to concentrate on my involvement in TeX Live and Debian. Those of you not interested in boring and melancholic look-back onto history can safely skip reading this one. For those a bit interested in the history of TeX in Debian, please read on. Debian releases and TeX systems The TeX system of choice has been for long years teTeX, curated by Thomas Esser. Digging through the Debian Archive and combining it with changelog entries as well as personal experiences since I joined Debian, here is a time line of TeX in Debian, all to my best knowledge.

Date	Version	Name	teTeX/TeX Live	Maintainers
1993-96	<1	?	?	Christoph Martin
6/1996	1.1	Buzz	?
12/1996	1.2	Rec	?
6/1997	1.3	Bo	teTeX 0.4
7/1998	2.0	Ham	teTeX 0.9
3/1999	2.1	Slink	teTeX 0.9.9N
8/2000	2.2	Potato	teTeX 1.0
7/2002	3.0	Woody	teTeX 1.0
6/2005	3.1	Sarge	teTeX 2.0	Atsuhito Kohda
4/2007	4.0	Etch	teTeX 3.0, TeX Live 2005	Frank K ster, NP
2/2009	5.0	Lenny	TeX Live 2007	NP
2/2011	6.0	Squeeze	TeX Live 2009
5/2013	7.0	Whezzy	TeX Live 2012
4/2015	8.0	Jessie	TeX Live 2014
???	???	Stretch	TeX Live 2015

The history of TeX in Debian is thus split more or less in 10 years teTeX, and 10 years TeX Live. While I cannot check back to the origins, my guesses are that already in the very first releases (te)TeX was included. The first release I can confirm (via the Debian archive) shipping teTeX is the release Bo (June 1997). Maintainership during the first 10 years showed some fluctuation: The first years/releases (till about 2002) were dominated by Christoph Martin with Adrian Bunk and few others, who did most packaging work on teTeX version 1. After this Atsuhito Kohda with help from Hilmar Preusse and some people brought teTeX up to version 2, and from 2004 to 2007 Frank K ster, again with help of Hilmar Preusse and some other, took over most of the work on teTeX. Other names appearing throughout the changelog are (incomplete list) Julian Gilbey, Ralf Stubner, LaMont Jones, and C.M Connelly (and many more bug-reporters and fixers). Looking at the above table I have to mention the incredible amount of work that both Atsuhito Kohda and Frank K ster have put into the teTeX packages, and many of their contributions have been carried over into the TeX Live packages. While there haven t been many releases during their maintainership, their work has inspired and supported the packaging of TeX Live to a huge extend. Start of TeX Live I got involved in TeX Live back in 2002 when I started building binaries for the alpha-linux architecture. I can t remember when I first had the idea to package TeX Live for Debian, but here is a time line from my first email to the Debian Developers mailing list concerning TeX Live, to the first accepted upload:

Date	Subject/Link	Comment
2005-01-11	binaries for different architectures in debian packages	The first question concerning packaging TeX Live, about including pre-built binaries
2005-01-25	Debian-TeXlive Proposal II	A better proposal, but still including pre-built binaries
2005-05-17	Proposal for a tex-base package	Proposal for tex-base, later tex-common, as basis for both teTeX and TeX live packages
2015-06-10	Bug#312897: ITP: texlive	ITP bug for TeX Live
2005-09-17	Re: Take over of texinfo/info packages	Taking over texinfo which was somehow orphaned started here
2005-11-28	Re: texlive-basic_2005-1_i386.changes REJECTED	My answer to the rejection by ftp-master of the first upload. This email sparked a long discussion about packaging and helped improve the naming of packages (but not really the packaging itself).
2006-01-12	Upload of TeX Live 2005-1 to Debian	The first successful upload
2006-01-22	Accepted texlive-base 2005-1 (source all)	TeX Live packages accepted into Debian/experimental

One can see from the first emails that at that time I didn t have any idea about Debian packaging and proposed to ship the binaries built within the TeX Live system on Debian. What followed was first a long discussion about whether there is any need for just another TeX system. The then maintainer Frank K ster took a clear stance in favor of including TeX Live, and after several rounds of proposals, tests, rejections and improvements, the first successful upload of TeX Live packages to Debian/experimental happened on 12 January 2006, so exactly 10 years ago. Packaging Right from the beginning I used a meta-packaging approach. That is, instead of working directly with the source packages, I wrote (Perl) scripts that generated the source packages from a set of directives. There were several reasons why I choose to introduce this extra layer:

• The original format of the TeX Live packaging information (tpm) were xml files that were parsed with an XML parser (libxml). I guess (from what I have seen over the years) I was the only one ever properly parsing these .tpm files for packaging.
• TeX Live packages were often reshuffled, and Debian package name changed, which would have caused a certain level of pain for the creation of original tar files and packaging.
• Flexibility in creating additional packages and arbitrary dependencies

Till now I am not 100% sure whether it was the best idea, but the scripts remain in place till now, only adapted to the new packaging paradigm in TeX Live (without xml) and adding new functionality. This allows me to just kick off one script that does do all the work, including building .orig.tar.gz, source packages, binary packages. For those interested to follow the frantic activity during the first years, there is a file CHANGES.packaging which for the years from 2005 to 2011 documents very extensively the changes I made in these years. I don t want to count the hours the went into all this Development over the years TeX Live 2005 was just another TeX system but not the preferred one in Debian Etch and beyond. But then in May 2006, Thomas Esser announced the end of development of teTeX, which cleared the path for TeX Live as main TeX system in Debian (and the world!). The next release of Debian, Lenny (1/2009), already carried only TeX Live. Unfortunately it was only TeX Live 2007 and not 2008, mostly due to me having been involved in rewriting the upstream infrastructure based on Debian package files instead of the notorious xml files. This took quite a lot of attention and time from Debian away to upstream development, but this will be discussed in a different post. Similarly, the release of TeX Live included in Debian Squeeze (released 2/2011) was only TeX Live 2009 (instead of 2010), but since then (Wheezy and Jessie) the releases of TeX Live in Debian were always the latest released ones. Current status Since about 2013 I am trying to keep a regular schedule of new TeX Live packages every month. These helps me to keep up with the changes in upstream packaging and reduces the load of packaging a new release of TeX Live. It also bring to users of unstable and testing a very up-to-date TeX system, where packages at most lack 1 month of behind the TeX Live net updates. Future As most of the readers here know, besides caring for TeX (Live) and related packages in Debian, I am also responsible for the TeX Live Manager (tlmgr) and most of upstream s infrastructure including network distribution. Thus, my (spare, outside work) time needs to be distributed between all these projects (and some others) which leaves less and less time for Debian packaging. Fortunately the packaging is in a state that making regular updates once a month is less of a burden, since most steps are automatized. What is still a bit of a struggle is adapting the binary package (src:texlive-bin) to new releases. But also this has become simpler due to less invasive changes over the years. All in all, I don t have many plans for TeX Live in Debian besides keeping the current system running as it is. Search for and advise to future maintainers and collaborators I would be more than happy if new collaborators appear, with fresh ideas and some spare time. Unfortunately, my experience over these 10 years with people showing up and proposing changes (anyone remembers the guy proposing a complete rewrite in ML or so?) is that nobody really wants to invest time and energy, but search for quick solutions. This is not something that will work with a package like TeX Live, sized of several gigabyte (the biggest in the Debian archive), and complicated inner workings. I advise everyone being interested in helping to package TeX Live for Debian, to first install normal TeX Live from TUG, get used to what actions happen during updates (format rebuilds, hyphenation patters, map file updates). One does not need to have a perfect understanding of what exactly happens down there in the guts (I didn t have in the beginning, either), but if you want to help packaging and never heard about what format dumps or map files are, then this might be a slight obstacle. Conclusion TeX Live is the only TeX system in wide use across lots of architectures and operating systems, and the only comparable system, MikTeX, is Windows specific (also there are traces of ports to Unix). Backed by all the big user groups of TeX, TeX Live will remain the prime choice for the foreseeable future, and thus also TeX Live in Debian.

Hello dear readers, It has been quite some time since I blogged on Planet Debian,so today, I just want to give some news to fellow Debian pals. My involvment in Debian is still there. I'm probably less visible nowadays, but I'm still actively working on some packages, monotiring some i18n activities and doing work on D-I. But, as you know, running has taken precedence nowadays and is still becoming a growing part of my life (along with my family, of course). This year, I had a first "summit" running the "Vulcain" trail race in French "Massif Central" (mountains in Central France), which was 80km and 3000m positive climb race. It was run mostly in snow and with quite bad weather conditions, a good training for more difficult races. I completed it in about more than 12 hours, for a race that finally had less than 60% finishers. Later on, most races were preparation races for the summer moutain races : I mostly ran three 50km trail races in the Paris and neighbourhood area. All of them were very good results with a good feeling. Some were run along with friends from the Kikourou.net web community, where I am now very active. My training was also strongly increased wrt former years (yes that *is* possible), peaking at more than 500km during May, where I was mostly on holidays all month long (lucky man). And now, the first Great Great Thing of the year is coming : La Montagn'hard, 110 kilometers, about 9000 meters positive climb, around Les Contamines, close to Mont-Blanc in French Alps. That is a Big One, indeed. Technically more difficult than the TDS race I ran last August, during DebConf (120km, but "only" 7000 meters climb). Montagn'hard is indeed known as one of the most difficult moutain trail races in France. I plan to complete it in about 29 hours....but that can indeed be 30, 32 or even 35, who knows what can happen? Given the very high temperatures over Europe this week (they'll peak at about 38 C on Saturday in the Alps), that will be an incredibly difficult challenge and we expect about only 40% finishers. A live tracking will be available for thos who care at http://chrono.geofp.com/montagnhard2015/v3/. Wish me luck ! Next challenge will be end of August, with the "Echappee Belle" race : 144km and 10.000 meters positive climb, still in French Alps (Belledonne range, this time). About 48 hours, or even up to 55, two nights out.....harder and hopefully better, faster, stronger...:-)

Mako's IronBlogger is a great idea. I often find myself postponing blog posts for a very long time, simply out of laziness. IronBlogger provides a nice community incentive to counter (my) laziness and blogging more often. As a related challenge, we have to face the fact that different subsets of our communities use different media to stay informed: mailing lists, blog (aggregators), social media, IRC, etc. Disparities in how they stay informed are a pity and can be countered using multiple medias at a time. Although I haven't blogged very often as of lately, I managed to keep the Debian (Developer) community informed of what happens in "DPL land" on a monthly basis, by the means of bits from the DPL mails sent to d-d-a. While the target of bits mails perfectly fits d-d-a, there is no reason to exclude a broader public from them. After all, who knows, maybe we'll find the next DPL victim^W candidate among Planet readers! Bonus point: blogging this also helped me realize that my mails are not as markdown-clean as I thought they were. I still have no IronBlogger squad, though. (And sharing beers with folks in the Boston area is not terribly handy for me ). Anyone interested in setting up a BloggeurDeFer in the Paris area? (SCNR)

---

Dear Project Members,
another month has passed, it's time to bother you again about what has happened in DPL land in November (this time, with even less delay than the last one, ah!). Call for Help: press/publicity team I'd like to highlight the call for help by the press / publicity teams. They are "hiring" and have sent out a call for new members a couple of weeks ago. The work they do is amazing and is very important for Debian, as important as maintaining packages or fixing RC bugs during a freeze. It is only by letting the world know what Debian is and what we do, that we can keep the Project thriving. And letting the world know is exactly what the publicity and press teams do. If you're into writing, blogging, or simply have a crush for social media, please read the call and "apply"! Interviews November has apparently been the "let's interview the DPL" month. I've spent quite some time giving interviews to interested journalists about various topics. For both my embarrassment and transparency on what I've said on behalf of Debian, here are the relevant links:

• audio interviewwith Karen Sandler for the Free as in Freedom oggcast by herself and Bradley M. Kuhn
• text interview with Raphael Hertzog for the People behind Debian series
• text interview for the Linux Certification Institute Italy (LICI) (note: the original of this one is in Italian; the English version is a translation by LICI)
• video interview with Amber Granger during last UDS

Assets

• the Video Team sprint approved in October has happened at beginning of November; report is still pending but the organizers are on it
• Christian Perrier reported about his trip to India mini-DebConf, even that he attended on behalf of the Project. I find amazing both the outcome of the event and Christian's report, a very good example of how to inform the Project when acting on behalf of it
• the hardware replacement for ftp,lists .d.o I've mentioned last month has been ordered, has arrived, and DSA have already put their hands on it for the setup. Many thanks to DSA and in particular to Martin Zobel-Helas for the logistics
• as an administratrivia, I've asked SPI to setup for Debian a "gift" credit card, i.e. a credit card with a limited, refillable budget. It is needed for using (with a safeguard) credits offered to the Project by public cloud providers (e.g. AWS' donation), as well as to use various kinds of services that we need from time to time

Legal advice (work in progress)

• I've sought and got from a former SPI lawyer a first legal advice on the relationships among trademark law and the procedures of a Free Software distro like Debian when distributing software subject to trademarks. I'm still waiting to seek a second advice from the current SPI lawyers (whom I've been keeping busy with other stuff). In the meantime I've pending a summary of what I've got thus far in the trademark-vs-DFSG thread. Stay tuned there!
• I've been working with SPI lawyers on a proposal of software patent policy that I think we should advertise to make explicit the position of the Debian Project on software patents. I see it as a continuation/completion of the FAQ we have already published on the subject. I'll let you know as soon as we reach a stable draft, that should be pretty soon.

Relationships with others

• I've been approached by members of the board of the OpenSource Initiative (OSI), about the soon to be open OSI affiliation program. They'd like to know if Debian is interested in being affiliated to OSI. I think we should and I'll eventually start a discussion on this topic. In the meantime, I welcome feedback from anyone who is interested in the topic.
• Thanks to the interest of Andrew Pollock, LaMont Jones, Florian Weimer and the Security Team, we are discussing with ISC to have Debian --- as a project, rather than as individuals who just happen to maintain ISC software in Debian --- become member of all forums relevant for software we distribute (BIND, NTP, DHCP). They are doing all the coordination work, but I've anticipated I'll be happy to pledge for Debian membership.
• I've taken the first step to reach out to companies that have a strategic interest in Debian. According to discussion I've had with representative of such companies, they often face similar challenges in offering Debian support and in contributing back to Debian. I think we should offer a forum for them to discuss and find synergies, as well as explain our needs to them. An official mailing list might be such a place. Once we have a suitable forum ready, I'll propose to the press team to send out a corresponding call for companies. In the meantime, if you happen to know, or even work for, companies that might be interested, please ask them to get in touch with me.

Miscellanea

• I've had a chance to discuss with the editors of the SPDX specification about its relationship with DEP-5. Thanks to the help of Dominique Dumont work is already in progress to have a mutual converter among the two formats. Also, although with some bumps, work on finalizing DEP-5 has finally restarted.
• an interesting thread of a while ago is in need of some work to produce a useful outcome, i.e. a set of security guidelines for DDs. If you're willing to help, have a look at the thread
• some more mediation-fu has been going on during November; have a look at my daily logs below if you care about the details

Thanks for reading thus far,
and happy hacking.

---

PS as usual, the boring day-to-day activity log is available at master:/srv/leader/news/bits-from-the-DPL.*

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• J r my Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matth i
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

Logically, Argentina won against Scotland tonight after a.....quite boring match. Scotland, as expected for them unfortunately, wasn't able to put speed in their game, the only way to beat Argentina this year. Even with that poor game (Lamont, their rear player, was a disaster), Scotland finished quite close to ARG, who didn't play brilliantly with many approximations (Hernandez being a bit arrogant, trying to kick too many drop goals) and a bit of luck. So, nothing really impressive in that match. Does that mean that South Africa has better chances to qualify for the final: who knows? Argentina can be unpredictable...but it seems they are a little bit burned out (they don't really have 30 top players and some of their key players appear tired). The semi-finals will feature France-England (about 50-50 chances from what we saw up to now) and South Africa-Argentina (60-40, in my opinion). Next week-end, Stade de France.

Logically, Argentina won against Scotland tonight after a.....quite boring match. Scotland, as expected for them unfortunately, wasn't able to put speed in their game, the only way to beat Argentina this year. Even with that poor game (Lamont, their rear player, was a disaster), Scotland finished quite close to ARG, who didn't play brilliantly with many approximations (Hernandez being a bit arrogant, trying to kick too many drop goals) and a bit of luck. So, nothing really impressive in that match. Does that mean that South Africa has better chances to qualify for the final: who knows? Argentina can be unpredictable...but it seems they are a little bit burned out (they don't really have 30 top players and some of their key players appear tired). The semi-finals will feature France-England (about 50-50 chances from what we saw up to now) and South Africa-Argentina (60-40, in my opinion). Next week-end, Stade de France.

We had a great time yesterday evening at the cabane sucre (sugar shack). It was about a 1-hour drive to the Sucrerie de la Montagne, a Quebec historic site near Rigaud, just a few kilometers from the Ontario border. We went with a group of friends, mostly anglophones, most of whom had never been to a sugar shack before. Late March and early April are when the maple trees are giving their sap for syrup, and the rableries (sugar farms) host big dinners at their farms for city guests. It's a great way to get a taste of traditional Qu bec culture. It was pretty cold when we got there -- we still have snow on the ground in Montreal so we all wrapped up as warm as we could. Poor Amita June fell in a puddle as we were walking across the parking lot, which caused not a small amount of crying, so Maj and I cleaned her up in the car. But the tears cleared up as we got close to the sucrerie. Amita called out, "BUCKETS!!" when she saw all the taps in the sides of the maples. There must have been 1000 tapped trees right near the main lodge. The sucrerie itself was a pretty impressive set-up. 4-5 buildings in an 18th-century rural style, hewn from logs, caulked with clay. There was a big outdoor fire with people sitting around, but we edged our way into the bakery, first thing, where we saw a few dozen loaves of bread baking in the stone oven. Then we went into the main dining hall -- dozens of tables laid out for guests. We were big enough to take our own table, and AJ took a high chair at the end. Each table had a quart bottle of maple syrup on it. The first course was split pea soup (a habitant classic), followed by a brunch-y meal of omelettes, mashed potatoes, beans, fresh bread, ham, sausage, meatballs, and torti re, the classic Qu becois meat pie. For dessert, we had coffee, maple sugar pie (you can feel the enamel of your teeth coming off), and... pancakes with maple syrup. All during dinner we were serenaded by a band playing classic Qu bec folk tunes on traditional instruments, including a saw. We waddled out of the cabin, and I wasn't looking forward to the walk to the car, which made me glad that there was a horse-drawn carriage waiting for us. The "carriage" was about the size of a flat-bed truck, pulled by two Clydesdales that must have been 3 meters tall at their ears. Amita loved seeing the horses and taking a ride, and I loved not having to walk. It's a good time -- I highly recommend it for anyone who hasn't had the experience. tags: quebec sugar shack

RoCoCoCamp I spent most of the day today sending out invitations to wiki people about RoCoCoCamp. RoCoCo is the Montreal version of RecentChangesCamp -- it's an "unconference" about wiki technology and wiki culture happening 18-20 May 2007 here. I've been pretty frantic about contacting people since I got involved in a serious way in RoCoCo in February. but I want to make sure that people who are involved in wiki, or more generally in technologies for community and collaboration, can make reasoned decisions about coming. We've got a really exciting group coming already, of course, and I don't mind anyone missing it because of schedule conflicts or lack of funds. But I'm torn up inside thinking there are people who want to come to RoCoCoCamp who just don't know about it. Please, reader: if you have any suggestions for wiki developers or practitioners, or other people who might benefit, Contact me and let me know. Or just pass along the RoCoCo URL to them, and make sure they know that they're invited. tags: rocococamp wiki recentchangescamp invitations

Montreal Tech Entrepreneur Breakfast Tomorrow morning is the third Montreal Tech Entrepreneur Breakfast, 9AM at Bistro Etc. on av Mont-Royal, corner of Chambord. This is the 3rd monthly MTEB, and I'm pretty excited about it. I missed the February event through ignorance, and the March event because I was in Austin. I'm determined not to miss this one! tags: montreal entrepreneurship breakfast mteb

These are the current translation ratios for French and Czech in unstable, after 12 days of "blitz l10n NMU". Nothing happened yesterday, which explains why I didn't post. Today, a few packages uploads in unstable should have improved the stats for French. However, this is also the day where dpkg-cross introduced 3 strings without prior notification to translators. A good occasion to test my "Please interact with translators" new script..:-) Czech has improved a lot as a consequence of numerous package uploads after my strong activity during the week-end. Thanks again to all these responsive maintainers. So, now we're hunting tha last remaining parts for French:

• postfix, on its way by LaMont Jones
• s390-dasd, a D-I component, already completed in D-I SVN and which will be uploaded by Frans along with all other D-I updates
• conserver, which has indeed been uploaded today by J rgen H gg
• libpam-rsa, which I'll sponsor in a few minutes
• dpkg-cross, as explained above

Another package will soon appear, out from NEW: emdebian-tools, uploaded by Neil Williams, who took care to request for translation updates in debian-i18n. Thanks, Neil.

My post about securing an office received many comments, so many that I had to write another blog entry to respond to them and also add some other things I didn't think of before.

One suggestion was to use pam_usb to store passwords on a USB device. It sounds like it's worth considering, but really we need public key encryption. I don't want to have a USB device full of keys, I want a USB device that runs GPG and can decrypt data on demand - the data it decrypts could be a key to unlock an entire filesystem. One thing to note is that USB 2.0 has a bandwidth of 30MB/s while the IDE hard drive in my Thinkpad can sustain 38MB/s reads (at the start - it would be slower near the end). This means that I would approximately halve the throughput on large IOs by sending all the data to a USB device for encryption or decryption. Given that such bulk IO is rare this is feasible. There are a number of devices on the market that support public-key encryption, I would be surprised if any of them can deliver the performance required to encrypt all the data on a hard drive. But this will happen eventually.

Bill made a really good point about firewire. I had considered mentioning it in my post but refrained due to a lack of knowledge of the technology (it's something that I would disable on my own machines but in the past I couldn't recommend that others disable without more information). Could someone please describe precisely which 1394 (AKA Firewire) modules should be disabled for a secure system? If you don't need Firewire then it's probably best to just disable it entirely.

To enable encryption in Fedora Core 6 you need something like the following in /etc/crypttab:

home_crypt /dev/hdaX /path/to/key
swap /dev/hdaX /dev/random swap

Debian uses the same format for /etc/crypttab.

The Peregrine blog entry in response to my entry made some really good points. I wasn't aware of what SUSE had done as I haven't done much with SUSE in the past. I'm currently being paid to do some SUSE work so I will learn more about what SUSE offers, but given the SUSE/MS deal I'm unlikely to use it when I don't have to. Before anyone asks, I don't work for SUSE and given what they have just done I will have to reject any offer of employment that might come from them.

I had forgotten about rsh and telnet. Surely those protocols are dead now? I use telnet as a convenient TCP server test tool (netcat isn't installed on all machines) and never use rsh. But Lamont was correct to mention them as there may be some people still doing such things.

The Peregrine blog made an interesting point about Kerberised NFS being encrypted, I wasn't aware of this and I will have to investigate it. I haven't used Kerberos in the past because most networks I work on don't have a central list of accounts, and often there is no one trusted host.

I strongly disagree with the comment about iSCSI and AoE "Neither protocol provides security mechanisms, which is a good thing. If they did, the additional overhead would affect their performance". Lack of security mechanisms allows replay attacks. For example if an attacker compromises a non-root account on a machine that uses such a protocol for it's root filesystem, the victim might change their password but the attacker could change the data back to it's original values even it if was encrypted. Encryption needs to have sequence numbers embedded to be effective, this is well known - the current dmcrypt code (used by cryptsetup) encrypts each block with the block ID number so that blocks can not be re-arranged by someone who can't decrypt them (a weakness of some earlier disk encryption systems). When block encryption is extended to a network storage system I believe that the block ID number needs to be used as well as a sequence ID number to prevent reordering of requests. CPU performance has been increasing more rapidly than hard drive performance for a long time. Some fairly expensive SAN hardware is limited to 40MB/s (I won't name the vendor here but please note that it's not a company that I have worked for), while there is faster SAN hardware out there I think it's reasonable to consider 40MB/s as adequate IO performance. A quick test indicates that the 1.7GHz Pentium-M CPU in my Thinkpad can decrypt data at a rate of 23MB/s. So to get reasonable speed with encryption from a SAN you might require a CPU which is twice as fast as in my Thinkpad for every client (which means most desktop machines sold for the last two years and probably all new laptops now other than the OLPC machine). You would also require a significant amount of CPU power at the server if multiple clients were to sustain such speeds. This might be justification for making encryption optional or for having faster (and therefore less effective) algorithms as an option.

I believe that the lack of built-in security in the AoE and iSCSI protocols gives a significant weakness to the security of the system which can't be fully addressed. The CPU requirements for such encryption can be met with current hardware even when using a strong algorithm such as AES. There are iSCSI accellerator cards being developed, such cards could also have built in encryption if there was a standard algorithm. This would allow good performance on both the client and the server without requiring the main CPU.

Finally the Peregrine blog entry recommended Counterpane. Bruce Schneier is possibly the most widely respected computer security expert. Everything he does is good. I didn't mention his company in my previous post because it was aimed at people who are on a strict budget. I didn't bother mentioning any item that requires much money, and I don't expect Counterpane to be cheap.

Simon noted that developing a clear threat model is the first step. This is absolutely correct, however most organizations don't have any real idea. When advising such organizations I usually just invent a few possible ways that someone with the same resources and knowledge as I might attack them and ask whether such threats seem reasonable, generally they agree that such things should be prevented and I give further advice based on that. It's not ideal, but advising clients who don't know what they want will never give an ideal result.

One thing that I forgot to mention is the fact that good security relies on something you have as well as something you know. For logging in it's ideal to use a hardware security token. RSA sells tokens that display a pseudo-random number every minute, the server knows the algorithm used to generate the numbers and can verify that the number entered was generated in the last minute or two. Such tokens are sold at low prices to large corporations (I can't quote prices, but one of my clients had prices that made them affordable for securing home networks), I will have to discover what their prices are to small companies and individuals (I have applied to evaluate the RSA hardware). Another option is a GPG smart-card, I already have a GPG card and just need to get a reader (this has been on my to-do list for a while). The GPG card has the advantage of being based on free software.

One thing I have believed for some time is that Debian should issue such tokens to all developers, I'm sure that purchasing ~1200 tokens would get a good price for Debian and the security benefits are worth it. The use of such tokens might have prevented the Debian server crack of 2003 or the Debian server crack of 2006. The Free Software Foundation Fellowship of Europe issues GPG cards to it's members, incidentally the FSFE is a worthy organisation that I am considering joining.