/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
