Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consider dropping -D option #34

Open
garlick opened this issue Jul 31, 2023 · 3 comments
Open

consider dropping -D option #34

garlick opened this issue Jul 31, 2023 · 3 comments

Comments

@garlick
Copy link
Member

garlick commented Jul 31, 2023

Problem: the -D,--dirent NEWNAME option is described as follows

After scrubbing the file, scrub its name in the directory entry,
then rename it to the new name. The scrub patterns used on the
directory entry are constrained by the operating system and thus
are not compliant with cited standards. This option only works
with a single target.

It seems like this is likely no more secure (in terms of obliterating data) than a rename, and thus offers a false sense of security.

A user could simply follow the scrub command with a rename if that's what they want.

@pete4abw
Copy link
Contributor

-D newname could cause problems with multiple files where there may be a name collision. But it MAY be useful when someone not only wants to scrub a file, but conceal the purpose of the file by renaming it. For example, scrubbing and renaming "Confidential whistle-blower letter about Company XYZ.doc" would shield its existence.

@garlick
Copy link
Member Author

garlick commented Jul 31, 2023

I guess my point is

scrub -D newname "Confidential whistle-blower letter about Company XYZ.doc"

is not a whole lot more convenient than

file="Confidential whistle-blower letter about Company XYZ.doc"
scrub $file
mv $file newname

and the former makes people feel like they're achieving some kind of secure deletion when in reality the two commands have about the same effect.

@pete4abw
Copy link
Contributor

Not to mention that with files on modern systems, it's not guaranteed that scrub will even wipe every part of the file with journaling and backup file systems. I won't cry if they're removed. shred has its -u option which deallocates and removes a file. Something to consider. Maybe the concept of -D is confusing, but perhaps -r can be enhanced???

Delete FILE(s) if --remove (-u) is specified. The default is not to remove
The optional HOW parameter indicates how to remove a directory entry:
'unlink' => use a standard unlink call.
'wipe' => also first obfuscate bytes in the name.
'wipesync' => also sync each obfuscated byte to the device.
The default mode is 'wipesync', but note it can be expensive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants