While looking at the bugs against the release-notes package I saw still some open bugs for sarge?! I think they should be either closed or marked properly, though for now I just left them untouched. Because I don't have write access (yet?) to the CVS repository, I prepared some patches for some issues. As I know I'm quite dense in explanations, I hope some people can improve them so they can be safely included in the Release Notes I spotted quite some bugs regarding the sarge to etch upgrade path and some bugs which are already acted on, but only need a last review AFAICS. As both these categories are already worked on by other people I'm happy to skip them for now I hope my patches fasten the work on the Release Notes as the release is very near...

Since my mail to debian-devel-announce we as Release Team actually don't consider any packages that don't fix RC bugs in etch anymore. This doesn't mean packages which have bogus RC bugs will be considered, nor that packages which don't have any RC bugs filed, but still are RC buggy won't be considered. It also doesn't mean we are considering packages with RC bugs in unstable like upgrading from some intermediate version to another. Security bugs are still considered anyway, though if they don't make it in time they'll have to go via security.debian.org. Main blockers for the release are at the moment the (hopefully) last kernel upload and the release notes. Other things that still have to be taken care of are preparing the detailed release procedure, building the CDs and preparing the announcement...

Anyone wants to join in the Luke Kenneth Casson Leighton fanclub? And these unfortunately aren’t candidates for DeFuBu

Theses days, I've been looking for a way to have crypto-containers in Debian. I wanted something easy to use, easy to move but still quite secure, which wouldn't require root access to the box, and as an option could use my gpg key.

I looked closely at two projects:

* cryptsetup/luks

The nice thing is that you only have one file containing all your crypted filesystem, it uses the Linux unified key management system (luks), and you are able to use a gpg key to crypt the data. I didn't tried it yet, because there are some drawbacks which I find really important. It uses multiple commands for every operations (creating the container, mounting and unmounting it).

For creating the crypto container you need to:
- create the file
- use it as a loop device (root access)
- initialize the container
- open the container
- create a filesystem on it
- mount it

Each time you want to mount it, you need to:
- create the loop device from the file
- open the container
- mount it

It surely can be wrapped, but that may be difficult to deploy. And you need root access for all operations (you can mount/umount without it using fstab, pmount or things like that, but still it's using privilegied access). And the major drawback, I think, is that the container size is fixed. You choose it when you create the initial file which you'll mount as a loop device. I don't know if there's a way to extend it after creating crypto-container, but anyway it'll need to be manual.

* encfs

encfs is fuse-based, so it doesn't require anything, beside fuse support in the kernel and your user belonging to fuse group. No need to root access nor anything. You create the container with only one command, then mount or umount it with only one command too. You can add and remove files from the container without asking yourself about disk usage or something, because the container is "expanded" (see after) when you add files, automatically.

There are two drawbacks in encfs, for me:
- crypto-container isn't a file, but a folder, with files and folders using crypted filenames but real size. (more or less, because you can use options to modify it but you won't hide a 20MB file for example). It's less secure than a one-file crypto-container where you can't determine how many files there are in it (and with crypsetup/luks, you won't be able to determine how much space is used in the container as the size is fixed anyway). It's less easy to move around, put on an usb key or transmit. You can tar it, yes, but you lose the comfort.
- you can't use a gpg key

In the end, I guess I'd like something like .dmg OSX Disk Images, which can be encrypted. They are really easy to use, as far as I could have seen. Maybe not so secure, but this is a bruteforce attack against master password (1024 bits RSA key), not against 128bits aes key of the container.

Anyway, I've setup an encfs folder here, but am still looking for something wich would improve the situation.

After asking for useable CA Software, I have finally settled on using EasyRSA. This is what I did to come across the packaging shortcomings of EasyRSA in Debian. Storing your CA Be sure that your CA is stored in a secure place. Don’t store it online, and make it accessible only to yourself. In my opinion, storing the the CA in a cryptoloop container file on a small 32 MB USB stick is a good idea. Cryptloop is rather easy today and available in the stock Linux kernel. I commonly use grml-crypt to manage the crypto loopback stuff:

sudo grml-crypt start /media/usb4/cryptoloop $MOUNTPOINT

Gotcha: don’t confuse sudo’s “password” prompt with grml-crypt’s “Enter LUKS passphrase” prompt, the cryptoloop password won’t bring you anywhere on the sudo prompt. Preparing the CA directory For the CA, create a dedicated directory in the mounted cryptoloop file system. You’re originally supposed to copy the entire EasyRSA directory tree in there, but I’d recommend to only link the files from your system’s EasyRSA directory to automatically take advantage of distribution updates. You’ll need at least these links:

lrwxrwxrwx 1 mh mh   56 Dec 25 23:23 openssl.cnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf
lrwxrwxrwx 1 mh mh   52 Dec 25 23:22 pkitool -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool
lrwxrwxrwx 1 mh mh   60 Dec 25 23:23 whichopensslcnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf

ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf .

Configuring your CA The only thing you cannot link is the vars file which contains your CA’s local settings:

export EASY_RSA=“$(pwd)”
export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”
export KEY_CONFIG=$($EASY_RSA/whichopensslcnf $EASY_RSA)
export KEY_DIR=“$EASY_RSA/keys”
# Issue rm -rf warning
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
export KEY_SIZE=1024
export CA_EXPIRE=3650
export KEY_EXPIRE=3650
export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus.de”
export KEY_EMAIL=“mh+easyrsa-mh-openvpn@zugschlus.de”
export PKCS11_MODULE_PATH=“dummy”
export PKCS11_PIN=“dummy”

Comments have been removed from this file. Better copy the file from /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars and edit it to your needs. I added the two PKCS11 variables since you won’t otherwise be able to issue certificate requests. Creating the CA Next, decide on a shell instance where you will do most operations, and source vars in there. Next, run /usr/share/doc/openvpn/examples/easy-rsa/2.0/clean-all. If you do this in a directory of an already-in-use EasyRSA CA, you’ll need to restore your backup. To actually initialize the CA, run pkitool --initca --pass. If you do not give the --pass parameter, you’ll create a CA that can issue certificates without asking for a passphrase, which might not be a brilliant idea. Choose a reasonably secure pass phrase. Creating Certificates - the simple and suboptimal way You can now simply proceed to create an arbitrary number of pairs of “private” keys and associated certificate by simply calling pkitool <clientname> and/or pkitool --server <servername>. Depending on your security policy, you can mandate the private keys to be protected by a passphrase (adding --pass to the command lines), but you’ll have the expense of being asked for the passphrase every time you start a new openvpn daemon. Creating Certificates the Right Way I have put the “private” in quotes since the keys created this way are not really private: The key was created on the box hosting the CA, was stored on the local (crypted) file system and needs to be moved to the target system via a secure channel. Doing so the right way is harder than expected, so it is usually the better way to keep the private key really private by creating it directly on the target system. On the target system, you need OpenVPN installed, and openssl. After the certificate was created, you can remove openssl again. Creating a private key is part of a key-pair generation process that also leaves a certificate request. The contents of the certificate request is public, and you can safely move it to the CA box and convert it to a certificate by signing the request. You only need to make sure that nobody exchanges your target system’s certificate request for her own before you sign it as you might end up certifying a wrong identity. For the rest of this document we’re going to assume that you have ssh access to the target system and have verified the ssh host key, so that you can be reasonably sure to be connected to the right system. To create a certificate request, you can use this script, which I have called create-easyrsa-cert-req:

#!/bin/bash
set -u
TMPDIR=“/tmp”
export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”
export KEY_CONFIG=“/usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf”
export KEY_DIR=“$TMPDIR/keys.$$”
mkdir -p $KEY_DIR
export KEY_SIZE=1024
export KEY_EXPIRE=3650
export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus”
export KEY_OU=“$(hostname --fqdn)”
export KEY_EMAIL=“mh+$(hostname)-ovpn-cert@zugschlus.de”
export DEBUG=1
umask 077
if [ “$ 1:-foo ” != “server” ]; then
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr $(hostname)
else
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr --server $(hostname)
fi
mv $TMPDIR/keys.$$/* .
rm -rf $TMPDIR/keys.$$

When called without parameters, it creates a certificate request for an OpenVPN client certificate, and when you call it with “server” as parameter, it will create a server certificate request. In any case, it will leave two files in the current directory. They are named after the current host name, and have the extensions .csr and .key. The .key file is your private key. keep it private! The .csr file is the certificate request which you can now move to the keys subdirectory of your CA directory via scp or other means such as an USB stick. To do the actual signing, invoke pkitool --sign <hostname> and enter the CA passphrase. You can ignore the error message that there was no .key file to chmod. Gotcha, when signing a server certificate, use pkitool --server --sign <hostname>. Move Certificate to the target host You can now move the certificate to the target system. Since you’re probably going to need the root certificate and the certificate revocation list as well, you can move the .key file (if created on the CA system), the .crt file, and ca.crt to the target system. These files are public, so there is no need for a secure channel. Revoking Certificates Since an OpenVPN server’s only means of authentication is to check whether the certificate presented by a client is signed by the “right” CA, the only way to revoke VPN access is to revoke the certificate. This is also done on the CA system by calling /usr/share/doc/openvpn/examples/easy-rsa/2.0/revoke-full <client-name>. This creates a crl.pem file which contains a list of all revoked certificates. You need to have a mechanism to distribute that list to all systems that might need it, and it is recommended to have this automated. Remember, if you do not distribute the .crl file, the systems are not going to know about revoked certificates.

Woo! I've been looking for a lucene index inspection tool for the command line for about 6 months or so, ever since first trying to use luke over a forwarded X11 over ssh connection to a machine in the colo with a large(ish) (300,000 document) index... a couple of months ago I stumbled upon PyLucene - a python library that can play with lucene indexes, of course the first thing I did with it was package it (can't have random unpackaged software laying around the system after all, can you!), and then played for a bit, and joined the pylucene-dev mailing list. So, imagine my glee today when on that mailing list there's a post about plush - a Python LUcene SHell - fantasticness! Quickly threw that in to a package and tested it out against a lucene index laying around on my workstation, it worked nicely (couple of small bugs, but they've now been fixed in the trunk version), so, now that I had it packaged, straight off I went to the main indexing server and threw it at a large lucene index, it just worked. Fantastic. I'll add some links to my repository for pylucene and plush later, when I'm feeling slightly better, feel a little under the weather at the moment.

I'll be going to the LinuxDays in Luxembourg next week. As far as I know, there won't be an exhibition, so, no Debian booth. But I'll be giving a talk. It's not on one of my usual topics, but on security this time. The reason for this is, that I am giving this talk instead of Lukas Grunwald, who originally registered the talk but then couldn't give it. I am really looking forward to going there. I've never before been to Luxembourg and I am curious what it's going to be like. I am also looking forward to giving the talk, since it will be something very different from my usual ones and I am curious to see what differences there will be. If anyone of you is going to LinuxDays.lu too and wants to meet for coffee or a beer, drop me note!

Happy New Year! Happy 2007!

And a really happy one!

After the cloud of ideas and subjects on the last post, giving the clear idea that I should keep this blog more up-to-date, here is an important note that is missing (including old news that I should had post but didn't, sorry for that). I'm aware that a few people are interested in how the Debian NM process evolves from person to person, on my last update on that topic, I told you that I was recommended to the DAM by my AM. Almost three months later (2006-11-18) Myon (Christoph Berg, Front Desk Member) couldn't find my final report, he pinged my AM and one week later everything was fine again and I got approved to the next step: DAMnation. On the Christmas' evening I got a nice gift from Joerg, DAM approval. Yesterday (2007-01-02) I got the nice e-mail with the subject: New Debian maintainer Felipe Augusto van de Wiel (Thanks to James Troup, aka, elmo). The entire process took me 8 months and 10 days. I would like to say thanks to everybody that helped me pass thru this experience: Otavio Salvador (my advocate and mentor), Christian Perrier and Luk Claes (Mentors and Uploaders), Clément Stenac (my AM), Christoph Berg (Front Desk), Joerg Jaspert and James Troup (DAMs). They are directly involved in my NM process, but they were not alone, thanks for every single person that helped me with tips and hints, that took some time to teach me and all the people behind different projects in Debian (I really start naming everybody but then I realize that it got very large for Planet): Debian Brasil, Debian Volatile (aba, zobel, sgran), Release Team, Debian Women, Debian i18n Task Force and Debian l10n Brazilian Portuguese, Debian Weekly News Team, buildd.net project, Alioth admins and staff, Debian Installer Team, Debian Kernel Team, Debian Mentors, DebConf Team, OFTC Staff, Debian QA Team, Debian Doc Team, Debian WWW Team, Debian Admin Team (DSA)! People, you know who you are, thank you VERY much! You can check my Status Page to see more details about my NM process and more information about the acronyms used on this post. Now, Brazil has 17 Debian Developers (not counting the one that already retired). :-)

I am using Vim a lot to code in Python. One of the most important thing in Python is indent code properly as t uses indent to mark code blocks, and making that right is a bit painful, as you usually end mixing tabstops with white spaces, which makes code almost unreadable when you open it with an editor with a different tabstop setting. To avoid that, using whitespaces is recommended, but it would be nice that those could be inserted automtacally, and that is what the following lines of code added to your ~/.vimrc file make.

" Tip: set indent parameters for python files.
" Version: 0.1
" Date: 13 May 2006
"
" Description: most python scripts use four spaces for indenting, but
"              sometimes you will end up editing a script where tabs
"              are used; in these situations it can be useful to
"              automatically detect whether spaces or tabs were used,
"              and set some parameters (or call some functions) consequently.
"
" Usage: you can put this script in you vimrc and call the PyIndentAutoCfg
"        function with an autocmd associated to python files, or call
"        it manually, or put it in the python.vim syntax script, or... :-)
" Function to set parameters for python scripts that use
" spaces for indention.  This is also the default.  YMMV.
function PySpacesCfg()
  set expandtab " use spaces in place of tabs.
  set tabstop=8 " number of spaces for a tab.
  set softtabstop=4 " number of spaces for a tab in editing operations.
  set shiftwidth=4 " number of spaces for indent (>>, , ...)
  set smarttab
  set autoindent
  set smartindent cinwords=if,elif,else,for,while,try,except,finally,def,class
endfunction
" Function to set parameters for python scripts that use
" tabs for indention.  YMMV.
function PyTabsCfg()
  set noexpandtab
  set tabstop=4
  set softtabstop=4
  set shiftwidth=4
  set autoindent
endfunction
" This function returns 1 if the file looks like a python script
" that uses tabs for indenting, or 0 otherwise.
function PyIsTabIndent()
  let lnum = 1
  let max_lines = 100 " max number of lines to check.
  let got_tabs = 0
  let got_cols = 0 " 1 if the previous lines ended with columns.
  while lnum = max_lines
    let line = getline(lnum)
    let lnum = lnum + 1
    if got_cols == 1
      if line =~ "^\t\t" " at least two tabs, to prevent false-positives.
        let got_tabs = 1
        break
      endif
    endif
    if line =~ ":\s*$"
      let got_cols = 1
    else
      let got_cols = 0
    endif
  endwhile
  return got_tabs
endfunction
" Check the file, and run the relative function.
function PyIndentAutoCfg()
  if PyIsTabIndent() == 1
    call PyTabsCfg()
  else
    call PySpacesCfg()
  endif
endfunction
" Call the PyIndentAutoCfg function.  Uncomment this line if you've copied
" this script in the python.vim syntax file or something like that.
" call PyIndentAutoCfg()
au BufNewFile,BufRead *.py call PyIndentAutoCfg()

Also, if you want to convert a file using tabs to spaces, you can do it by using the following Vim commands.:

:set expandtab
:%retab

Update: Stefano posted about using filetype hook files instead of au groups. I think it is smarter, and I didn't knew about after/ dir in ~/.vim. So following Stefano's advice, you should put the ebove script in ~/.vimrc/after/ftplugin/python.vim, so it gets loaded automatically when you open a Python file.

Xmas Vim tip: use ~/.vim/after/ftplugin/XXX.vim Jose Carlos posted some Python tips for vim. I haven't yet looked thoroughly at the code, but still here is my Xmas Vim tip:

Avoid putting filetype-specific customizations directly in your ~/.vimrc using au groups which rely on specific filename extensions. It's better to put filetype-specific customizations for the filetype XXX directly in the file ~/.vim/after/ftplugin/XXX.vim (in the example it would be ~/.vim/after/ftplugin/python.vim), this way they would be loaded even when you manually do "set ft=XXX" on a file with whatever extension.

For the interested reader the "after" path step is justified by the vim "runtimepath" we use in Debian (cfr. /usr/share/vim/vimcurrent/debian.vim). It ensures your customizations will be loaded after system-wide customizations so that they can be overridden. Oh-Oh-Oh, Merry Christmas.

A few days ago I installed Debian/Etch on my Thinkpad. One of the reasons for converting from Fedora to Debian is that I need to run Xen and Fedora doesn't support non-PAE machines with Xen. Ironically it's hardware supplied to me by Red Hat (Thinkpad T41p) that is lacks PAE support and forces me to switch to Debian. I thought about just buying a new dual-core 64bit laptop, but that seems a bit extravagant as my current machine works well for everything else.

Feeling adventurous I decided to use the graphical mode of the installer. I found it a little confusing, at each stage you can double-click on an item or click on the continue button to cause the action to be performed. The partitioning section was a little unclear too, but given that it has more features than any other partitioning system I've seen I wasn't too worried (options of creating a degraded RAID array and for inserting a LUKS encryption layer at any level are really nice). The option to take a screen-shot at any time was also a handy feature (I haven't yet inspected the PNG files to see what they look like).

Another nice feature was the way that the GUI restarts after a crash. While it was annoying that the GUI started crashing on me (and would have prevented a less experienced user from completing the install) the fact that it didn't entirely abort meant that I could work around the problem.

I have not yet filed any bug reports against the installer because I have not done a repeatable install (there is a limit to how much testing I will do on my most important machine). In the next few days I plan to do a few tests of the graphical installer on test hardware for the operations that are important to me and file appropriate bug reports. I encourage others to do the same, the graphical mode of the installer and the new encryption and RAID features are significant improvements to Debian and we want them to work well.

I have realised that it won't be possible to get SE Linux as good as I desire before the Etch release, even if the release is delayed again. I'm not sure how many fixes can go in after the release (I hope that we could move to a model similar to RHEL - but doubt that it will happen). So I now plan to maintain my own repository of Etch SE Linux packages and for other packages which need changes to make them work in the best possible manner with SE Linux. I will append something like ".se1" to the version of the packages in question, this means that they will be replaced if a security update is released for the official package. Apart from the SE Linux policy packages (for which any security updates will surely involve me) the changes I am going to make will not be major and will be of less importance than a security update.

I will also add other modified and new packages to my repository that increase the general security of Etch. Apart from SE Linux all the changes I intend to host will be minimal cost issues (IE they won't break things or increase the difficulty of sys-admin tasks), and the SE Linux related changes will not break anything on non-SE systems. So someone who wants general security improvements without using SE Linux might still find my repository useful.

Hardware sucks. It just totally and utterly sucks. I purchased a 300 GB hard drive (plus a 3.5" USB disk drive enclosure) roughly 8 months ago which I encrypted using dm-crypt and then used it as a backup medium. And now the disk has died. No, this is not a software problem (that would be easy to deal with), the hardware is simply dead (it's making funny "klck" noises all the time). Mounting it via USB (using the USB enclosure) doesn't work at all anymore. I connected the disk via IDE in a PC and was able to mount it just fine (with cryptsetup luksOpen and all). A simple ls works, too (at least in the top-level directory). So I tried to copy the data over to another medium, but when accessing certain directories or files the system simply hangs and I get tons of funny kernel errors (and the disk makes even more and louder funny noises). Great. Stupid as I am, I also put data on the drive which I did not have backups of on other media (mostly because the data is huge, e.g. conference video recordings, large amounts of Creative Commons MP3s etc). OK, so I managed to get at least some small parts of my data, but now the disk is completely dead, I fear. I'll try to convice the vendor to give me a new drive, but I won't let them get their fingers on my data, i.e., I will not send the disk to them (yes, even though it is encrypted; crypto can be broken). Any ideas what else I could do? A professional "data recovery" service is not an option either, they usually cost 1000-2000 Euros (in the best case). What do you do for storing huge amounts of data nowadays? The only viable option I can think of is a RAID-5 (mdadm) with 3 or more disks in a silent PC which I can leave turned on 24/7. Unfortunately that costs non-trivial amounts of money. CDs are too small and they don't last too long either; the same is true for DVDs. Sigh...

Mozilla Firefox Locales In 2004, we had for every individual localization a dedicated source package in the Debian archive, such as: mozilla-firefox-locale-ar, mozila-firefox-locale-ca, etc. This is a mess from every point of view. First, it creates much overhead on the archive infrastructure side as well as on the maintainers one, and second, since it often results in localization packages out of sync with the browser, it is a major pain in the ass for the users. Mozilla Firefox Locales All In January 2005, Cesar Martinez Izquierdo introduced the common source package mozilla-firefox-locale-all which included most of the available localizations. That was the inital step to clean up the mess. Later, David Moreno Garza and Luk Claes took the package over and accompanied it through the Mozilla Firefox to Firefox transition. Iceweasel l10n In September 2006, I jumped in as the new maintainer. Since then, the package did continue to evolve:

• rebranding for the Firefox to Iceweasel transition (currently, the foreign locales are fixed, only the en-US locale included in iceweasel is not, patch is at #400721).
• renaming to use the proper l10n naming scheme ($ program -l10n-$ language and not $ program -locale-$ language ).
• with the inclusion of the Catalan and Ukrainian localizations, iceweasel-l10n includes now really all Iceweasel locales which were previously packaged seperately in Debian (Thanks again to Jordi Mallach and Eugeniy Meshcheryakov for their permission for inclusion).

Additionally,

• with the readdition of temporarily removed locales within the Firefox 2.0 release (he for Hebrew and pa-in for Punjabi, taken from 2.0.0.1-rc3),
• with the inclusion of unofficial but complete localizations (fa-ir for Persian and fur-it for Furlan),
• and the half-official localizations (ka for Georgian and ku for Kurdish, taken from 2.0.0.1-rc3),

iceweasel-l10n as of 2.0+debian.1-1 supports 43 languages in total. That is more than any other distribution (yes, including Ubuntu :) contains. Icelizard Currently, the locale packages for iceape and icedove are not unified. This September, I was writing to the some of the maintainers but they seemed not interested to fix it for Etch. I will try it again in 2007, my aim is to have proper unified localization packages for all icelizard applications in Lenny. Update: iceweasel-l10n 2.0.0.1+debian-1 adds Valencian localization, so supporting 44 languages now.

Hi Yesterday I did a new install of my notebook because I had LUKS and for a reason my laptop began to hang totally (with all installed kernels) after several seconds. This was also my first installation with compiz, I really like it even if it’s just eyecandy - it’s cool. _BUT_, then I installed the sun-java-* packages and also the netbeans package which is waiting in the NEW-queue, I can start it, but there’s no content inside the window? So i tested some other java programs and there exactly the same. Finally I found out that when you run compiz all java applications don’t have a content inside of the javax.swing.JFrame objects. Iceweasel seems also not to work (I’m still searching why), because when invoking on the console I don’t get any line of output - just no reaction. But I can blog - thanks to “drivel” which is also a very nice program in my opinion. Yeah, enough talking bad now - in general I’m very happy and it’s a very good system (compared to other days with unstable ), I think etch will become a really good distribution when I look at my notebook, it’s very simple to use, enough eyecandy, most hardware works out of the box. Special thanks for this to the GNOME-Team who did a really god job in the last months! Wish you a nice Sunday and have fun at work tomorrow (I have holidays )

aba recently announced the freeze of Debian Etch, which is great news. However, it now means that a lot of work is now important for the secure testing team. So, if you have time, please help us out and look through the list of vulnerable packages in the testing suite, and provide patches/upload fixes :) I'd like as many of these fixed as possible before we hand over to the stable security team.
I've also been actively recruiting recently. Luk has joined the team, and should also be helping to issue updates in the near future. Please come find me on IRC (Maulkin) if you want to help us produce a nice secure operating system :P

As this seems to be a post about testing security, I'll put a bit of a status update too:

• Updates now go through newklecker (aka: security.debian.org)
• The embargoed/unembargoed queues seem to work (mostly), whcih means that there should be a greater number of people who can do updates for stable
• We're working through all the outstanding issues which don't have CVE-IDs yet, and requesting them
• I'm working on various clamav signatures to find embedded code copies in other packages

On a mailing list some questions were asked about disk encryption, I decided to blog the answer for the benefit of others:

What type of encryption would be the strongest? the uncrackable if you will? im not interested in DES as this is a US govt recommendation - IDEA seems good but what kernel module implements this?

The US government (which incidentally employs some of the best cryptologists in the world) recommends encryption methods for data that is important to US interests (US military and banking operations for starters). Why wouldn't you want to follow those recommendations? Do you think that they are putting back-doors in their own systems?

If they were putting in back-doors do you think that they would use them (and potentially reveal their methods) for something as unimportant as your data?

I think that if the US military wanted to apply a serious effort to breaking the encryption on your data then you would have an assortment of other things to worry about, most of which would be more important to you than the integrity of your data.

I've read some good things about keeping a usb key for system boot so that anything on the computer itself is unreadable without the key - but thats simply just a physical object - I'd like both the system to ask for the passphrase for the key as well as needing the usb key

I believe that can be done with LUKS, however it seemed broken last time I experimented with it so I've stuck with the older operation of cryptsetup.

What kind of overheads does something like this entangle? - will my system crawl because of the constant IO load of the disk?

My laptop has a Pentium-M 1.7GHz and a typical laptop drive. The ratio of CPU power to hard drive speed is reasonable. For most operations I don't notice the overhead of encryption, the only problem is when performing CPU intensive IO operations (such as bzip compression of large files). When an application and the kernel both want to use a lot of CPU time then things can get slow.

More recent machines have a much higher ratio of CPU power to disk IO as CPU technology has been advancing much faster than disk technology. A high-end desktop system might have 2-3x the IO capacity
of my machine, but a single core would have 2-3x the computer power of the CPU in my laptop and for any system you might desire nowadays 2 cores is the minimum. Single-core machines are still on sale and still work well for many people - I am still deploying Pentium-3 machines in new installations, but for machines that make people drool it's all dual-core in laptops and one or two dual-core CPUs in desktop systems (with quad core CPUs on sale soon).

If you want to encrypt data on a P3 system with a RAID array (EG a P3 server) then you should expect some performance loss. But for a typical modern desktop system you shouldn't expect to notice any overhead.

aba recently announced the freeze of Debian Etch, which is great news. However, it now means that a lot of work is now important for the secure testing team. So, if you have time, please help us out and look through the list of vulnerable packages in the testing suite, and provide patches/upload fixes :) I'd like as many of these fixed as possible before we hand over to the stable security team.
I've also been actively recruiting recently. Luk has joined the team, and should also be helping to issue updates in the near future. Please come find me on IRC (Maulkin) if you want to help us produce a nice secure operating system :P

As this seems to be a post about testing security, I'll put a bit of a status update too:

• Updates now go through newklecker (aka: security.debian.org)
• The embargoed/unembargoed queues seem to work (mostly), whcih means that there should be a greater number of people who can do updates for stable
• We're working through all the outstanding issues which don't have CVE-IDs yet, and requesting them
• I'm working on various clamav signatures to find embedded code copies in other packages

It looks like November-December are the most popular months for people coming to visit me, or crashing at my place in their way to their final destination.

In November I had the pleasure to host Sulamita, while she was on her way to India. One of the most interesting girls I have met this year.

Baby Jesus left yesterday, after spending several days at my place. He brought Salmiakki, smoked salmon and smoked reindeer with him, which I used to like before I became vegan (and later pescatarian). The salmon was incredible, though.

Just as I was writing these lines, Luk, who was also going to stay at my place before The Extremadura QA Meeting called me from BRU airport claiming his ticket had been cancelled :( I called C sar and found out that the travel agent they work with had not bothered to confirm several people s flights, so he will be coming to Spain on the 13th, just like everyone else. He will not be staying at my place, and will miss out on the smoked reindeer, that will be eaten by some other carnivore, I guess .

The great man I got the Linksys from lies sick in my bed, and spends almost as much time at my place than at his own, so I guess he doesn t count.

Introduction: This guide will walk you through the creation of an encrypted filesystem using LUKS. LUKS is the Linux Unified Key Setup and is a standard format for linux hard disk encryption. It has a lot of interesting features such as using a key on a removable disk, keeping multiple keys, and more. This is the technology used by the Debian Installer (since etch beta3) and is quickly becoming a standard in the linux world. Who this guide is for: This guide is for anyone who wants to secure their data using an encrypted partition. While it is tailored to users of Debian, it should apply elsewhere in the linux world. This guide is intended to add an encrypted device to an existing install, if you are contemplating a fresh install, the Debian Installer will configure encrypted filesystems for you. Ready? Then let’s begin Prepare the partition (or other block device) to be used This can be a partition on disk, a logical volume in LVM or some other block device. For this example, I created a 40 GB volume in LVM.

• For a physical partition, you would need to have an entire partition available on disk. Instructions for this can be found from many other sources
• For LVM, create a partition like this
  lvcreate -n crypto_test --size 40g asimov-vol

Install cryptsetup This utility provides an interface into the code in the linux kernel that handles encrypted block devices. It’s packaged for Debian in both testing and unstable, stable has an older version and I don’t know whether or not it will work in the same manner.
apt-get install cryptsetup Set up encryption on the partition: This initializes the partition for encryption and sets the initial key. People not using LVM will want a path like /dev/hdxY where hdxY is the partition on their hard drive that will be used for encryption. Important! This command will wipe out anything on that partition

cryptsetup luksFormat /dev/mapper/asimov--vol-crypto_test
WARNING!
========
This will overwrite data on /dev/mapper/asimov–vol-crypto_test irrevocably. Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

Congratulation! You now have an encrypted block device! However, it’s not quite ready to use. Open and map the device: This opens the device (prompting for a passphrase) and maps it to a block device in /dev/mapper. This can be used like any other block device, and the encryption/decryption is transparent. The first path (/dev/mapper/asimov–vol-crypto_test) is the encrypted partition you set up earlier. The name (crypto_test) is the name of the volume, the block device will be mapped as /dev/mapper/<name>.

cryptsetup luksOpen /dev/mapper/asimov--vol-crypto_test crypto_test
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

Create the filesystem of your choice on the device: This is just like setting up any other block device. I use ext3, others may prefer different formats.
mkfs.ext3 /dev/mapper/crypto-test Add the definition to /etc/crypttab: /etc/crypttab is a list of encrypted devices that are mapped on boot. The format is <map name> <path to device> <key file> <options> Since we’re using a passphrase, we don’t have a key file.
crypto_test /dev/mapper/asimov--vol-crypto_test none luks Create a mount point: This is where the encrypted device will be mounted on your filesystem.
mkdir /mnt/crypto_test Add the device to /etc/fstab: /etc/fstab tells the computer where to mount different devices on the filesystem. The format is
<source path> <mount path> <type of filesystem> <options> <mount options options> <dump frequency> <fsck pass> More information can be found by reading man 5 fstab. You will want to add a line like this: /dev/mapper/crypto_test /mnt/crypto_test ext3 defaults 0 2 somewhere in this file. Update the initial ramdisk. The initial ramdisk is used to jumpstart the boot process and load modules for the kernel that it can’t load itself (such as drivers for block devices that contain the modules it uses). I’m not sure if this is needed or not, but I wanted to be on the safe side.
update-initramfs -u -k all Congratulations Now your encrypted filesystem is completely set up! Reboot the system and you will see it prompt you for your passphrase during the boot cycle. Once the password has entered, the encryption is completely transparent. If you want to use your encrypted filesystem before rebooting, simply type mount /path/to/mountpoint.