Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs, and it's also not guaranteed to work on filesystems with copy-on-write semantics. If you're really concerned with this, you should be doing full-disk encryption.
That's only true for GNU-based userlands, not BSD-based ones.
> Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs
And if the system properly TRIMs it might not be necessary at all, though that greatly depends on the SSD.
Sure, but installing (a subset of) GNU coreutils is probably going to pull in a lot fewer dependencies than this JavaScript command line tool. Plus, you can use ports, no need to mess with a seperate package manager (npm) and the associated package verification foibles.
> And if the system properly TRIMs it might not be necessary at all, though that greatly depends on the SSD.
The "depends on the SSD" is a big one. Various recent forensic papers have shown that it can take a while until a TRIM'd sector is actually erased by the firmware.
I still think that if this kind of thing causes worries, full-disk encryption is really the only sensible solution.
No objection here. Though the original note is right, you just pointed to the wrong tool:
> I still think that if this kind of thing causes worries, full-disk encryption is really the only sensible solution.
And full agreement there.
"rm -P" with the same caveats as the GNU implementation.
RM(1) BSD General Commands Manual RM(1)
-P Overwrite regular files before deleting them. Files are
overwritten three times, first with the byte pattern 0xff,
then 0x00, and then 0xff again, before they are deleted.I bet one could even shred a network socket.
dtal@reepicheep:~$ cat /dev/urandom | shred -
shred: -: invalid file typeYou need to point stdout to an actual file, like this:
shred > /my/secret/file.txt