On Tue, 27 Aug 2013 11:28:27 +0200 Liviu Andronic <landronimirc@xxxxxxxxx> wrote: > On Sun, Aug 25, 2013 at 7:15 AM, <tpgww@xxxxxxxxxxx> wrote: > > On Thu, 22 Aug 2013 12:45:59 +0200 > > "0.akowalski" <0.akowalski@xxxxxxxxx> wrote: > > > >> You also have my plus one ;-) > > > > I hope we all realise that this will really be just a more-sophisticated > > approach to security-by-obscurity. AFAIK there's no bullet-proof and > > widely-available approach to forcing multiple, nearly-simultaneous > > overwrites, or dealing with OS page-files. > > > I've now played around with the new Shred plugin and applying it on a > file yielded the following: > Failed to remove > /tmp/1001-emelfm2-svn-unpack.tmp~1/bcrypt-master/Makefile - Success > > Is this expected? No, the appended "success" is a glitch. > > Furthermore, I peeked at the source code (I couldn't yet find docs for > the plugin) and it seems to me that this is a home-grown > implementation for a shredding algorithm. Is there a good reason to > not just re-use the thoroughly tested shred command that comes with > most Linux distros (and allow for some plug-in config options, like > nature of rewrite---zeros or pseudo-randoms---and nr of rewrites)? For the reasons described in recent posts on this list, among other places - multiple overwrites are more fantasy than reality in too many contexts. The plugin does these: * for a 'normal' file, change the file size randomly (bigger) * fill the revised file with random content (or for links, a random target) * for all types of item, change the name randomly * put the item into /tmp or somewhere like that where lots of files would be * change the mtime and atime randomly * if possible, change some permissions * finally - delete it So, good luck with getting it back ! Regards Tom -- Users can unsubscribe from the list by sending email to emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by logging into the web interface.