On Thu, 2007-05-03 at 19:56 +0100, Philip Rowlands wrote: > On Wed, 2 May 2007, Peter Eckersley wrote:
> It's tricky to view security/performance tradeoffs to be anything but > ratchet-like, only ever towards security. Perhaps it's even preferable > to make --iterations be a mandatory argument, except for the breakage > that would cause to old scripts. > I think the disk density effect is a ratchet that's greatly in our favour. I think it's just a question of how we distribute the benefit of the ratchet between security and convenience. > Why 5 passes, and not 3 or 7? Any of these would be fine by me :) I don't have proof that nobody could ever read something that had been scrubbed 3 times, but once one has factored in the observation that security is <= the weakest link, I really doubt that this will be a serious problem in the real world. On the other hand, people avoiding shred because it's too slow is a serious problem :). > > BTW, are you also working to add solutions for journaled filesystems, > such as the "s" (EXT2_SECRM_FL) attribute? (I have no knowledge that > this is effective, but the API certainly exists.) We're certainly working on making sure that userspace chattr()s the attribute. Apparently, for many journalling filesystems (ext3 and maybe Reiser, IIRC), shred should still work pretty well as-is -- I guess that's because the filesystem promises metadata consistency, not data consistency. For the others, we can certainly ping the developers about it. We could potentially work on patches too, but that's less likely unless there's an obvious case where the patch would make a lot of real-world difference. -- Peter Eckersley [EMAIL PROTECTED] Staff Technologist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
