Hello Johnny, Judging by the Ubuntu bug listings at https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bugs?field.status:list=NEW, it would appear that the bug has already be reassigned to cryptsetup, and it doesn't appear in the listing of bugs in cryptmount.
I'm still not sure there's a particularly clean solution to this problem, and all of the ideas suggested so far against this bug seem vulnerable to quite mundane special cases (e.g. using a large swap file temporarily installed via a loopback device.) Your UUID proposal may be part of a better solution, but seems to require a change in the format of swap partitions themselves. That might involve ensuring that encrypted swap partitions always have a header in which a UUID is readable *before* decryption (as with the LUKS format). However, that could require quite widespread changes in the kernel, mkswap, etc. The (partial) solution I'm trying in 'cryptmount' is to look at the degree of randomness (entropy) of a partition before running mkswap. Only if the raw data on the partition, or its decrypted version, doesn't look totally random or totally featureless, will mkswap be allowed to run. This feature is currently part of the beta release of cryptmount-4.2. I'm hoping this will significantly reduce the risk of accidental dataloss in a way similar to the /etc/crypttab issue, even if it can't eliminate it entirely. Kind regards, RW Penney -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/474258 Title: Extremely dangerous! cryptswap killed my partition -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
