Re: summer of code - scrub feature

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, Mar 22, 2009 at 08:07:06PM -0400, Thor Lancelot Simon wrote:
> On Sun, Mar 22, 2009 at 11:21:45PM +0000, Alistair Crooks wrote:
> > 
> > Yes, and there's the ability to have f?truncate(2) catered for by
> > overwriting with random gibberish.
> > 
> > Oh, and not having to remember to specify -P to rm for any file that
> > you want to make sure is overwritten, because it's too late once those
> > data blocks make it back onto the freelist. I suppose you could take the
> > hit and alias rm -P, and wait while directory trees take ages to delete.
> > We're all too busy anyway, these days, and could do with a break.
> 
> There's another problem -- spared sectors.  There is a US Government
> standard for erasing files and disks, which used to specify procedures
> for securely erasing individual files.  That portion of the standard
> was rescinded: for the government's purposes, anyway, only whole-disk
> erase will suffice, and if the disk will not allow spared-out sectors
> to be overwritten with the mandated erase patterns, even that is not
> enough.
> 
> This is why I stopped improving rm -P after I read the _current_ 
> version of the standard.  It is probably good enough, now, for most
> people's purposes -- but it is _not_ good enough for the purposes of
> those who care enough to do what the relevant standard says; and it
> can't be.

Yeah, sector sparing is a problem that is not meant to be addressed
by this project. It's another one in itself, and is highly dependent
on the disk itself, since it's the disk that's changing the rules
underneath the OS's feet. Whcih isn't to say that the project couldn't
look at the steps needed to deal with sparing in a portable and efficient
way (hah!), but I feel it's out of the main scope, and could be left
as an exercise at the end "for extra credit".
 
> The other problem is that the WAPBL journal will have pieces of file
> data in it.  Aggressively overwriting the log after transactions have
> been committed will _murder_ performance.  The best solution to all this
> is to just use cgd!

Requiring the use of cgd is certainly one way of addressing the
problem.  Another way would be to give up using computers completely
since we can never be sure that data will not be copied without our
prior knowledge and sent back to the HQ of the cabal's mothership.
 
> One project which would really be neat would be to make cgd use
> opencrypto so that, on multicore hosts, its cryptography could happen
> on whatever CPU had least to do.  Even laptops have two or four cores
> or threads now!

Sounds like an excellent idea to me - I don't know if the list of
projects has been closed or what, but I'm sure one of the SoC admins
can help us out here.

Thanks,
Alistair