Feature request: secure delete

[jung-kurt]

After successfully archiving a plaintext file, it would be desirable if the --delete option securely obscured the input file before unlinking it. This could be with a configured program such as shred (something like --sdelete[=program]?) or perhaps it could be done natively with routines that enchive already uses. Even simply overwriting the input file with the output file would have some value.

[skeeto]

I saw this issue last night and thought about it for awhile since I can think of one reasonable argument for it. However, I'm going to follow my initial intuition and say no. The most obvious problem is that there's just no way to securely wipe a file using the standard file system interface, especially with modern filesystems and hardware. There are two layers fighting against you. First, file system almost certainly has a journal of some sort, and it may even use copy-on-write (the default in btrfs), perhaps specifically to prevent you from losing data. At best you'd need some kind of custom ioctl() to request secure deletion directly from the underlying file system. Even if this exists, this is much too complicated to put in Enchive. Your idea of calling out to shred is better, leaving those complications to another tool. However, shred is an outdated program that, as far as I can tell, still does the same old, dumb thing. Unless you're on a really primitive file system, it's probably best to forget shred. Then below this, solid state storage has wear leveling, and drive controllers now do clever things behind your back. There's simply no interface to deal with these issues. The argument in favor is basically what you were getting at: --delete is merely for convenience. It doesn't do anything smart. It literally unlinks the input file if the output was written successfully. It doesn't even call fsync() first to make sure the encrypted file has made it to storage (at least as far as the clever drive controller reports). Add a dumb "secure" wipe option fits right in with this. In 2018, secure file deletion is little more than false security, which is worse than no security. So I prefer the latter in order to avoid nasty surprises. If you want to bet on shred working as advertised, you'll have to run it yourself. enchive archive private.txt && shred -u private.txt IMHO, the proper way to solve this problem is full disk encryption (LUKS, etc.). It doesn't matter how the file system works since it's entirely inside the encrypted volume. It doesn't matter how the drive controller works since it's entirely outside the encrypted volume. And all file deletions are *actually* secure by default, though for a slightly different threat model than shred-style secure deletion. Full disk encryption is not redundant with Enchive since it serves a different purpose.

[jung-kurt]

Every point you make is persuasive and well-articulated. I agree with your conclusion.

Thanks for your thorough consideration of this -- I understand the issues now. How I wish all software practitioners shared your insight and intellectual honesty!