[Pkg-cryptsetup-devel] Bug#465902: Bug#465902: cryptroot remote unlocking on boot feature

Jonas Meurer jonas at freesources.org
Sat Feb 16 00:45:10 UTC 2008

On 15/02/2008 debian at x.ray.net wrote:
> this patch is part of three patches (initramfs-tools, cryptsetup,  
> dropbear) which enable mkinitramfs to create initramfss that provide the  
> ability to log in and unlock a cryptroot during the boot process from  
> remote via ssh.


This sounds like an interesting approach. As I got from #465901, this
will enable dropbear per default if cryptroot is detected. While I like
the idea to be able to enable ssh support for initramfs, I object
against this default behaviour. Not everyone with cryptroot is in need
of remote access during boot process. Thus I suggest to disable the
whole feature per default, and make it configurable in any case.

Also, please resend the patch in unified format (diff -rNu).

> in the initramfs scripts, the target might be unlocked (from remote) in  
> the background. so on non-successful cryptsetup exit, check whether the  
> target is unlocked, only otherwise act on it as a failure.
> for this unlocking in the background (and if successful, killing the  
> waiting cryptsetup), the cryptcreate script is added.
> to call this unlocking script from remote, dropbear has to be added to  
> the initramfs, so dropbear is added to the suggested list.

I have to admit that I don't get that. In your patch, a script
/sbin/cryptcreate is created, which itself uses the variables
$cryptcreate and $crypttarget. This script is made executable, but I
cannot find the place where it actually is executed. Also, how does the
script know about the variables used by it?


More information about the Pkg-cryptsetup-devel mailing list