• Home
  • History
  • Annotate
  • only in this directory
NameDateSize

..12-Jul-20116

aclocal.m4H A D22-Sep-200430.1 KiB

ChangesH A D22-Sep-20043.3 KiB

config.h.inH A D22-Sep-20042.6 KiB

configureH A D04-Apr-2006154.2 KiB

configure.inH A D20-Jan-20101.1 KiB

COPYINGH A D22-Sep-20041.3 KiB

CreditsH A D22-Sep-2004743

depcompH A D22-Sep-200411.8 KiB

doc/H27-May-20155

install-shH A D22-Sep-20045.5 KiB

lib/H27-May-20158

Makefile.amH A D22-Sep-2004153

Makefile.inH A D18-Jan-201013 KiB

missingH A D22-Sep-200410 KiB

mkinstalldirsH A D22-Sep-2004726

READMEH A D22-Sep-20041.7 KiB

src/H27-May-201511

srm.specH A D22-Sep-2004961

srm.spec.inH A D22-Sep-2004971

README

1This is srm, a secure replacement for rm(1). Unlike the standard rm,
2it overwrites the data in the target files before unlinkg them. This
3prevents command-line recovery of the data by examining the raw block
4device. It may also help frustrate physical examination of the disk,
5although it's unlikely that completely protects against this type of
6recovery.
7
8Srm uses algorithms found in _Secure Deletion of Data from Magnetic
9and Solid-State Memory_ by Peter Gutmann and THC Secure Delete (the
10overwrite, truncate, rename, unlink sequence). 
11
12Srm was originally released under the GPL. Versions 1.1 and later are
13released under the X11 license, which is much less restrictive. For
14your convience, some commonly needed modules are distributed in the
15/lib directory. These may be under different licenses.
16
17All users, but especially Linux users, should be aware that srm will
18only work on file systems that overwrite blocks in place. In
19particular, it will _NOT_ work on resiserfs or the vast majority of
20journaled file systems. It should work on ext2, FAT-based file
21systems, and the BSD native file system. Ext3 users should be
22especially careful as it can be set to journal data as well, which is
23an obvious route to reconstructing information.
24
25As of this writing, the state of the Linux kernel prohibits any
26planning about solving the above problems prior to the 2.6 kernel
27series. Indeed, by then, other developments may make the entire issue
28a moot point. Either the LSM framework will make writing the kernel
29portion trivial, or encrypted file systems will be common enough to
30make srm nearly useless.
31
32Patches, donations, and notes of encouragement are all appreciated and
33should be sent directly to the author.
34
35Matt Gauthier <elleron@comcast.net>
36