Re: Shred: Add recursion operations [PATCH]

[Amr Ali]

On 12/10/2011 01:56 AM, Eric Blake wrote:
> On 12/09/2011 04:27 PM, Amr Ali wrote:
>> Purpose is what drives my modifications towards shred. If you do work on
>> multiple files (and that *does* have a high probability), with a simple 
>> command
>> line regular expression (e.g. './*') you are in fact recursing over files of 
>> the
>> first level of depth of the current directory node, which conditionally, 
>> having
>> it recurse on all directory nodes on multiple levels is only an expected
>> behavior
> 
> If you want to recurse over multiple layers, your first thought should
> be to use 'find', not '-r' - by having 'find' at the forefront of your
> toolbox, you will be able to solve your recursion issues for a LOT more
> tools, not just limited to shred, and in a manner portable to POSIX (and
> thus usable on more systems) rather than relying on GNU extensions.
> 
> Furthermore, have you not been listening to our arguments that shred on
> files is worthless on most modern file systems?  It doesn't destroy data
> unless you do it over entire partitions.  Making shred recursive would
> be a bad move, because it would give users a false sense of security
> (oh, I can shred lots of files in one command line), when in reality,
> doing a recursive shred is just disk churn.  If you want lots of files
> properly shredded, it is faster, and more reliable, to run something
> like 'shred /dev/sdb2' over the entire partition, than it is to try to
> recurse over the files on /dev/sdb2 and shred each in turn.  But that
> still means you have to plan ahead - if you anticipate needing to shred
> lots of files, create a disk partition for those files.
Please check my response to Bob Proulx post. I completely understand that shred
has became of very limited use, but there's use for it nonetheless, an important
one actually, which is to securely delete data from a drive that is structured
by a non-journaled old file system. (e.g. N+1 [where N != 0] USB partial-keys on
non-journaled file system that are utilized in an IDA (Information Dispersal
Algorithm) based FDE setup.)

I understand your point of view, and I completely agree with it from a pragmatic
perspective. But from a usability perspective, I still don't see how adding
find, hence dramatically increasing the complexity ratio for a simple feature,
would be any simpler than adding '-r' to shred.
> 
>> Before taking a dive at coreutils source code, which was my very first time, 
>> I
>> always enjoyed just using the *functionalities* it does provide, I knew how 
>> they
>> do work at very low level details, but this is not the drive behind using 
>> them.
>> It's simply the desired quantifiable result. The low level technical
>> particularities are almost always expected to be abstracted away from usage.
> 
> The beauty of free software is that you are free to make your patch, and
> use it yourself, even if we don't take it upstream.  I'm glad it was a
> positive learning experience for you, even if we don't take this
> contribution.  And hopefully you will still find other things to
> contribute that do fit in with the coreutils philosophy.
> 
True, and I understand if I can't come up with more common use cases that would
justify encouraging working on files on modern file systems, but again,
non-journaled file systems will remain as long as their is a security concern. I
also understand that this might be a corner case and also not justifiable.

But I could think of a compromise, maintaining usability while levitating the
warning levels on usage on top of modern file systems as that what really is the
culprit here, and not adding a facility to shred that really is an expected
upgrade over the concern of having users use it insecurely over journaled file
systems is not the solution here, but rather education is the solution, even
enforced education in the form of a run-time warning is a very reasonable
solution to me.
>>>
>>> Finally, if you DO manage to convince me, then we would need copyright
>>> assignment before your patch could be applied.
>>>
>> Should I use `assign.change.manual`? if so which email I should be sending 
>> this
>> to, after signing it? That of course if I did convince you.
> 
> http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING#n454
> 
> Use request-assign.future, and send the initial coordination mail to
> assign AT gnu DOT org.  From there, they will help you with the
> additional paperwork, and if you are a US resident, it is now possible
> to do things electronically instead of snail mail.
> 

-- 
Amr Ali

signature.asc
Description: OpenPGP digital signature