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.
Hello Johnny,
Judging by the Ubuntu bug listings at /bugs.launchpad .net/ubuntu/ +source/ cryptsetup/ +bugs?field. status: list=NEW,
https:/
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