Re: shred plugin
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Tue, 27 Aug 2013 20:54:12 +1000
On Tue, 27 Aug 2013 11:30:47 +0200
Liviu Andronic <landronimirc@xxxxxxxxx> wrote:
> On Tue, Aug 27, 2013 at 11:28 AM, Liviu Andronic <landronimirc@xxxxxxxxx>
> wrote:
> > Dear Tom,
> >
> >
> > 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?
> >
> > 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)?
> >
> One more thing: When launching Shred on a file, the dialogue asks
> whether you want to _delete_ the file. I think both the message and
> button should use _shred_.
Would need to re-factor the dialog code. Surely a user can remember what action
was initiated a few seconds before ??
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.
Other related posts:
