cryptsetup: Cannot delete a Keyslot from itselfs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cryptsetup |
Fix Released
|
Unknown
|
|||
cryptsetup (Debian) |
Fix Released
|
Unknown
|
|||
cryptsetup (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: cryptsetup
lsb_release -rd :
Description: Ubuntu 8.04.2
Release: 8.04
apt-cache policy cryptsetup :
cryptsetup:
Installed: 2:1.0.5-2ubuntu12
Candidate: 2:1.0.5-2ubuntu12
Version table:
*** 2:1.0.5-2ubuntu12 0
500 http://
100 /var/lib/
The bug I reported for debian (etch/lenny) also exists under debian hardy.
see : http://
It is not possible to "suicide" a luks encrypted disk, however it is a "feature" (there is a warning message before doing that)
This is the output that explains the problem :
root@computer:~# cryptsetup luksFormat /dev/loop0 key0.bin
WARNING!
========
This will overwrite data on /dev/loop0 irrevocably.
Are you sure? (Type uppercase yes): YES
Command successful.
root@computer:~# cryptsetup luksAddKey --key-file key0.bin /dev/loop0 key1.bin
key slot 0 unlocked.
Command successful.
root@computer:~# cryptsetup luksDelKey --key-file key0.bin /dev/loop0 0
key slot 0 unlocked.
No remaining key available with this passphrase.
Command failed.
root@computer:~# cryptsetup luksDelKey --key-file key0.bin /dev/loop0 1
key slot 0 unlocked.
Command successful.
root@computer:~# cryptsetup luksDelKey --key-file key0.bin /dev/loop0 0
WARNING!
========
This is the last keyslot. Device will become unusable after purging this key.
Are you sure? (Type uppercase yes): YES
key slot 0 unlocked.
No remaining key available with this passphrase.
Command failed.
A patch solving this issue for hardy is attached
Changed in cryptsetup: | |
status: | New → Triaged |
Changed in cryptsetup: | |
status: | Unknown → Fix Committed |
status: | Unknown → Fix Committed |
Changed in cryptsetup: | |
status: | Fix Committed → Fix Released |
Changed in cryptsetup (Debian): | |
status: | Fix Committed → Fix Released |
I just checked and it was corrected upstream in revision 41 of trunk
http:// code.google. com/p/cryptsetu p/source/ diff?spec= svn47&r= 41&format= side&path= /trunk/ lib/setup. c&old_path= /trunk/ lib/setup. c&old=38