"Enter passphrase" for LUKS/cryptsetup breaks usplash

This is probably due to the fact that usplash will only unlock the root partition. The boot process continues and the second partition is mounted by cryptsetup during the init.d boot sequence, so it's displayed in console mode and remove usplash. I don't know if this can be fixed easily.

Should this bug get fixed in usplash or cryptsetup?

I have another configuration now, so I cannot test hardy's usplash.
There have been added several new "dialogs" in usplash i.e. when testing a device for errors. Maybe there is also a new "dialog", when another encrypted partiton than root needs a password. Is somebody able to test this easily?

Updated hardy beta 1, this bug still exist. Since usplash now show fsck verifications in graphic mode, I'm pretty sure that it can be updated to do the same with cryptsetup.

I've written a patch to one of cryptsetup package scripts so it uses usplash to ask the password.

The file: /lib/cryptsetup/cryptdisks.functions

The patch is attached. Try it out please. It's working here.

Oh, I'm also attaching the complete script for the ones that doesn't know how to patch a file.

File: /lib/cryptsetup/cryptdisks.functions

Thanks for your patch! From now on, I can confirm that your patch works. However, I can still reproduce an important security issue described in bug 62751 when entering the password through usplash (password is echoed in plain text in the console).

We should be 100% sure that this security flaw does not appears when enabling this patch.

I've done some tests here without success.

I think that this is an issue with usplash, since it's the one in charge of presenting the prompt and reading from keyboard.

Anyway... I can't think of an example of how some attacker might use it.

I'm not sure if Ubuntu should use it anyway, but, for my personal use, it's way better than that ugly prompt.

At least now I know this issue exists. Thanks.

The patch looks good (almost identical as the "cryptroot") that runs with initramfs when installed in encrypted LVM with the alternate CD. However, due to the security reasons explained in bug 55159, it is still not suitable for a upload into intrepid or hardy, at least until the "clear password in console" security problem is fixed.

Yeah, I based on it since they should have the same behavior.

Does it work properly from initramfs?

Yes, as described in bug 55159, cryptsetup password through usplash works correctly in initramfs, but not when started through init.d.

I have the same issue here. It's really disturbing as I already invested some hours getting rid of all the other trouble, cryption caused together with usplash. Maybe there's a way to do the crypt-stuff within the initramfs too? Just as workaround untill there's a real solution.

Is it right that the patch isn't working if there's a fsck running before the cryptodisks are started? Cause then something seems to fill the password input with some strange huge text, so the monitor is full of stars. Without fsck running before, I have no problems with the patched file.

Yes, it's another issue which would need attention before we add cryptsetup prompt to usplash. I don't think that adding current cryptsetup init.d processes to initramfs is a acceptable solution, cryptsetup should still be started from init.d at this stage and when it is configured this way. Keeping the actual configuration until the bug gets fixed is clearly not a problem, it just don't give a good user experience because it doesn't look great, but it works correctly.

IMO, This cosmetic bug should only be fixed if it doesn't cause any regression.

Yes, I've observed this bug here too. I'll try to integrate the script into initramfs first unlock when I have some time.

Where does this bug with fsck come from? Maybe the file the password is read from (/dev/.initramfs/usplash_outfifo) isn't empty but filled with the output of fsck? If so, why can't you just empty it before prompting for the password and then reading it?
"cat" will block if (as it should be) there's no line or byte to read from the file. I don't know, if there's any commandline tool to do this properly, but something like this works:

sudo -s
echo -e "some stupid input just to have something within the file" > /dev/.initramfs/usplash_outfifo
cat -u /dev/.initramfs/usplash_outfifo

So maybe we can put something like this right before prompting for the password in order to empty the file the password is read from.

10111 : Would that be a solution for bug 55159 ? We should also be sure that the password is not echoed in the console or anywhere in plain text. Also I thought more about your proposition to add cryptsetup prompt in initramfs instead of init.d and this can make sense since filesystem is not necessary mounted at this stage, cryptsetup only creates the /dev/mapper device. I was probably wrong, this might be a interesting solution. It would also not ask for cryptsetup password in the middle of the boot process, but directly at start, which woud be more interesting for the final user IMO.

No, I propose this as solution for the bug, that the current patch for this issue isn't working if there's a fsck before. I'd like to know, whether you (evidently you know better all this usplash stuff than I) concern this as possible solution or not.

Bug 55159 doesn't appear here. I tried your instructions in comment #6 (https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/55159/comments/6) but I couldn't see any value I entered.

Having to enter all the passwords the same time in the boot process is an enhancement I didn't thought about. But I agree with you that this brings better user experience. Who's "the one" we have to propose moving the password prompts to the initramfs?

This bug was fixed in the package cryptsetup - 2:1.0.6-6ubuntu1

---------------
cryptsetup (2:1.0.6-6ubuntu1) intrepid; urgency=low

  * drop almost all ubuntu specific changes from the cryptsetup package,
    because they have been merged in debian. Thanks a lot!
  * merge from debian, remaining changes:
    - remove versioned build-depency on libdevmapper-dev, we are using a
      rather sophisticated loop for making sure the root filesystem appears.
  * debian/rules: fix location of ltmain.sh
  * don't exit usplash anymore in the init script. LP: #110970, #139363
  * Disable error message 'failed to setup lvm device'. It is harmless, and
    caused by the fact that the udev rules provided by lvm2 are setting up
    the lvm on their own. In debian the scripts here are responsible for this
    but obviously fail in ubuntu. LP: #151532

cryptsetup (2:1.0.6-6) unstable; urgency=high

  * Don't cat keyfile into pipe for do_noluks(). cryptsetup handles
    --key-file=- different for luks and plain dm-crypt mappings. This time
    really (closes: #493848). Thus again upload with urgency=high.

cryptsetup (2:1.0.6-5) unstable; urgency=high

  * Fix watch file to not report -pre and -rc releases as superior.
  * Remove the global var $SIZE from cryptdisks.functions again but keep the
    extended value checks.
  * Remove the udev rules file also in preinst, code taken from example at
    http://wiki.debian.org/DpkgConffileHandling. Thanks Marco d'Itri.
    (closes: #493151)
  * Remove duplicated configuration of --key-file in $PARAMS at do_noluks().
    (closes: #493848).
  * Invoke mount_fs() and umount_fs() in cryptdisks_start, add
    log_action_begin_msg() and log_action_end_msg() to both cryptdisk_start
    and cryptdisks_stop.
  * Copy fd 3 code from do_start and do_stop to cryptdisks_start and
    cryptdisks_stop to fix "keyscript | cryptsetup". (closes: #493622)
  * This upload fixes two RC bugs, thus upload with severity=high.

cryptsetup (2:1.0.6-4) unstable; urgency=medium

  [ David Härdeman ]
  * Make sure $IGNORE is reset as necessary, patch by Thomas Luzat
    <email address hidden> (closes: #490199)
  * Use askpass in init scripts as well (closes: #489033, #477203)

  [ Jonas Meurer ]
  * Don't copy_exec libgcc1 in cryptopensc initramfs hook, as it's already
    copied by copy_exec /usr/sbin/pcscd automaticly. Thanks to Evgeni Golov
    <email address hidden>. (closes: #490300)
  * Remove the udev rules file again as the relevant rules are now provided
    by dmsetup package which cryptsetup depends on.
  * Add splashy support to askpass, thanks to John Hughes <email address hidden>
    for the patch. (closes: #492451) The support is limited to cryptroot
    though, as splashy freezes for passphrase input dialogs from initscripts.
    Document that in README.Debian.
  * Now that askpass is used as keyscript for interactive mode, it's not
    necessary to set cryptsetup parameter '--tries=$TRIES' and TRIES=1 for
    interactive mode anymore in cryptdisks.functions.
  * Implement special treatment for random passphrases now that we use
    "--key-file=-" for all situations. Only necessary in do_noluks.
  * Fix the passphrase prompt string in...

Marking this bug as a duplicate of bug 110970 so we can merge our discussion with ubuntu-dev that already put some work on it too.