SHRED for EXT3?

[Mike McCarty]

Scot L. Harris wrote:
> On Wed, 2005-07-27 at 13:10, Mike McCarty wrote:
> 
> 
>>I am familiar with these, but the primary objection to what he wrote
>>is that this is a journalled file system. IOW, the writes take place
>>to a separate location and then are committed.
> 
> 
> So the real question is, how can you flush the journalled information
> prior to running the shred utility?  And where is the journalled
> information stored prior to being committed?

Not entirely. One issue is that if I overwrite the file, the location
which contains the original data is *not* the place the overwrite
is done to. The journaled info is another, but valid, issue.

> Another question is, is the customer requiring a DOD level of deletion
> or is a standard rm sufficient?  Realizing that with significant effort
> that some of the data may be recoverable?  

What exactly they mean by "permanently eradicate" is not specified, but
I seriously doubt DOD standards. I've been requested to e-mail them
updates simply by using PKZIP with an encryption key. That's hardly
what one would call "secure". OTOH, they do specify that backups
containing that information be "destroyed". I asked what that meant,
and was told "just break the CDs".

> I suspect that if you make a best effort at deleting all project files
> and disposing of any backups of these files they are not going to be
> concerned with the possible use of forensic recover techniques to get
> portions of those files back.

I suspect you are right. I don't foresee any real problem. But I'd
like to comply with the contract in the most comprehensive way
possible. I'm not so concerned with them complaining, as I am with
my own ethical standards. I signed that contract, and I want to be
a man of my word.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!