I'm using gpg for decrypting the disk passphrase (which was generated via /dev/urandom), though, such passphrases MAY contain unprintable characters. However, a contruct like the following: cryptfs_key=$(gpg ${gpg_options} ${key} 2>/dev/null 1>/dev/console) will work fine with most (printable) characters, but will strip/convert the others. echo -n $(echo -ne 'z\x0Az') | hexdump -C will result into 00000000 7a 20 7a |z z| 00000003 the sequence "\x7a\x20\x7a" is wrong - it should be "\x7a\x0a\x7a" instead. There're more chars that do not work this way for sure. My workaround so far, was, not to store the cryptfs_key in a environment variable, instead, I used /dev/shm/.cryptfs_key to decrypt the gpg encrypted key, and removed that file ASAP. p.s.: this once worked a long long time ago, but I'm sick of patching dm-cryptfs-start.sh on each update (a passphrase change on that disk (1TB size) would take much longer as well). regards ;)
I'm currently rewriting this entire script, the current version of what I am using doesn't have this problem. I will hopefully get around to committing this shortly.
thanks thanks ;)
any updates? besides?
nope. Things have been changing around in baselayout and I've been chronically short of time. I'd suggest switching the volume to crypsetup-luks so you can change the passphrase on it more easily, writing files anywhere, no matter how briefly is more of a security risk then having it with printable chars imo. I've got more time now then I've had in a while and a desire to fix all the cryptsetup bugs so I'll see what I can do to get things a little better.
you don't really have a commandline for me for doing it? I mean, I just can't backup 1TB storage. I now for a long time thought about switching over, but the way on doing it w/o buying another TB held me back.
New completely rewritten version of the scripts are out. Please check cryptsetup-luks-1.0.3-r3 and let me know if that fixes your problems.
closing this as I believe it is now fixed.
