[throwaway7767]

This functionality already exists in GNU coreutils, it's done by the shred(1) command. No need to install any extra third-party software, shred is already installed.

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.

[masklinn]

> This functionality already exists in GNU coreutils, it's done by the shred(1) command. No need to install any extra third-party software, shred is already installed.

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.

[throwaway7767]

> That's only true for GNU-based userlands, not BSD-based ones.

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.

[masklinn]

> Sure, but installing (a subset of) GNU coreutils is probably going to pull in a lot fewer dependencies than this JavaScript command line tool.

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.

[DannyBee]

"That's only true for GNU-based userlands, not BSD-based ones. "

  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.

[GalacticDomin8r]

> That's only true for GNU-based userlands, not BSD-based ones.

"rm -P" with the same caveats as the GNU implementation.

[Jaepa]

for BSD-base systems there is srm (secure remove), which overwrites, renames, & trucates before unlinking.

https://www.freshports.org/security/srm/

[wiredfool]

Looking at man shred, apparently one can shred stdout.

[brudgers]

"Shredding stdout" sounds like the highest complement for a command line utility.

[gcr]

Why not? One can shred any file descriptor. :-)

I bet one could even shred a network socket.

[emodendroket]

Is there any advantage to specifically disabling that?

[dTal]

And yet it doesn't "work":

  dtal@reepicheep:~$ cat /dev/urandom | shred -
  shred: -: invalid file type

[colanderman]

Your command points stdin to the output of some random command. Even if you actually redirected stdout (pipe to cat, not from), it still wouldn't work, because cat's stdin isn't a file.

You need to point stdout to an actual file, like this:

    shred > /my/secret/file.txt

Why would you do this? At the end of a long batch of commands that all write to some temporary file opened on stdout. Not uncommon in shell-land.