On Sun, 2010-06-27 at 00:34 +0200, Jonas Meurer wrote: > To be honest, I don't like the idea of using the bug tracking system > as > a discussion archive. As maintainer, I like to keep the count of open > bugs against packages low. It's generally better to document > controversial topics in the package or at documentation pages. Well,... actually it is a bug,.. it's however probably not limited to Debian itself.
> Maybe it's time to setup a cryptsetup wiki page at wiki.debian.org, > which documents all these discussion we have. I don't have the time to > maintain it, so feel free to setup, as long as mention all arguments, > and try to keep the documentation neutral ;-) Don't think that a wiki will help much, as it's a development issue,.. I guess that we have to bring all "affected" maintainers (at least lvm2,mdadm,dm-crypt) to one table. I was about to write an email to all you guys,... describing the problem in detail, and asking what everybody would like to do,... but I can of course skip you if you're currently not interested. > this is a real problem, and I'm glad that you started the discussion > at the linux kernel mailinglist. It would be great to fix the shutdown > process in debian in a way that all keys are wiped from memory. If you're glad I don't understand why you dislike this bug... > both init scripts tell you that the to-be-stopped dm-crypt device is > still busy. Just run '/etc/init.d/cryptdisks stop' on your running > system to see what happens: > > Stopping early crypto disks...cswap1 (busy)...ctemp1 (busy)...clvm1 > (busy)...done. Ah ok,.. I know why I didn't notice... it seems you don't let the initscript action fail, if some were still busy. lvm2 does,.. so I see the big red "failed" ;) > I think that this already became clear in the discussion: remount,ro > should be enough to prevent data loss. But it's not enough security > wise, as the dm-crypt key still is in memory. Yes.... > Next cryptsetup package upload should fix the boot/halt order of > cryptdisks(-early) initscripts for non-root encryption. But I don't > know > a solution for encrypted root devices, and I've never heard about > haltramfs or something like that. I guess the best idea is if we discuss the security thingy for root-devices at lkml. May I propose, that if doing cryptdisks-[early] stop,... and some devices could not be stopped, you give an status of failure back. Then it will be more clear that this action has failed,... and I guess we can close this bug. Cheers, Chris. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
