Bugzilla Bug 181503

/lib/rcscripts/addons/dm-crypt-start.sh checks for a luks header (line 43) even
when the target is swap. this leads to an exhaustive read on /dev/urandom for
the password.
imho it should abort with an error when a luks header is detected on a swap
target, because there could be important data in danger.

I can verify this bug and have encountered it for nearly a year. <a
href="http://www.mail-archive.com/gentoo-amd64@lists.gentoo.org/msg06122.html">Mailing
list</a> and forums were no help and I suspected it was due to inadequate amd64
testing (I had unmasked the package manually) until recently.

i'm not quite sure that i understand your concern. If someone has the wrong
things in /etc/conf.d/dmcrypt (was cryptfs) then it can lead to an exhaustive
read on /dev/urandom. I guess it's not ideal but surely the obvious thing
should be put the right thing in the configuration file and you don't have an
issue.

A.middleton: I don't think this bug is what you've been experiencing at least
nothing in that thread seems relevant.

Sorry for the bad formulation. 
When people want to reuse an existing volume for swap, and the volume contains
a luks header, they will likely encounter the exhaustive read, because most
people don't think of erasing the header in that case. They simply don't know
that the script assumes there is no luks header in the swap use case, and it's
not that easy to figure out what the problem is in that situation. At least I
had to read the script to understand what was wrong.
A simple solution would be to ignore the header in the swap use case, but I
don't think this would be a good idea, for the same reason mkfs.xfs checks for
an existing filesystem. In an ideal world the script would not only check for a
luks header but also for an existing filesystem before overwriting, however
this may be overkill.

i've ammended the script, try 1.0.5-r1 let me know how you find it. thanks for
reporting