Overwrite/destroy not-empty partition due to lack of vol_id from udev

Binary package hint: cryptsetup

SRU update rationale:
1. impact of the bug on users:
Bugs which may, under realistic circumstances, directly cause a loss of user data.
Bug can destroy entire partition on user system while booting, if the user change hard drivers order.

2. how the bug has been addressed
In Lucid we are using blk_id, which works.
In Karmic the solution is different - the attached patch makes no_vol_id return failure instead of success if vol_id program is missing, therefore it will stop the overwrite of user partition.

3. A minimal patch applicable to the stable version
the one-liner patch is attached

4. Detailed instructions how to reproduce the bug
Was described below by the reporter

5. A discussion of the regression potential of the patch
Very unlikely IMHO.
It just stops overwriting existing partition and using it to create without a question encrypted swap

----

/lib/cryptsetup/checks/{un_,}vol_id are supposed to check for a type of file system on a disk volume. Functions from /lib/cryptsetup/cryptdisks.functions use those checks to determine whether it is safe to destroy the contents of a volume by e.g calling luks create on it:

    PRECHECK="/lib/cryptsetup/checks/un_vol_id"

    [...]

       if ! pre_out=$("$PRECHECK" "$src" 2> /dev/null) && \
           [ "$MAKESWAP" != "yes" ] && \
           ! /lib/cryptsetup/checks/vol_id "$src" swap >/dev/null; then
                log_warning_msg "$dst: the precheck for '$src' failed: $pre_out"
                return 1
        fi

    [...]

     cryptsetup $PARAMS create "$dst" "$src"

/lib/cryptsetup/checks/{un_,}vol_id rely on /lib/udev/vol_id from the udev package. In Karmic, vol_id it is no longer present. Most unfortunately, in this case the checks *pass* with mere warning:

if test ! -x "/lib/udev/vol_id"; then
  echo " - WARNING: vol_id from udev is not available, impossible to run checks."
  exit 0
fi

I would argue that exit 0 should be exit 1 instead, otherwise it can lead to silent data corruption in case the disks connected to the machine change. Here is how it happend to me:

I installed Karmic on HDD1; at that time it was the only drive in the box, and thus it was detected as sda. The installer created this entry in /etc/crypttab:

cryptswap1 /dev/sda3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

After that, I connected my second drive, HDD2, to the box. It happend to be connected to the first port of the SATA controller, so when I booted off HDD1, hard drive were detected as follows: HDD2: sda, HDD1: sdb. As a result, my ext3 partition on HDD2 ("new" sda3) became corrupted because of missing vol_id in udev and this bug.

It looks like the move from vol_id to blkid from util-linux is uderway; Debian already has /mnt/lib/cryptsetup/checks/blkid, but the same problem is present there too:

if test ! -x "/sbin/blkid"; then
  echo " - WARNING: blkid from util-linux is not available, impossible to run checks."
  exit 0
fi

which means data corruption if blkid is missing and your disks changed since the time /etc/crypttab was created.