Bug 1215160

Wipe was last touched upstream 2009-11-01, so not surprised here. Consider it abandoned. What do you expect the distribution to do? The tool itself is not as secure or useful as you may think for modern storage devices, setups, and file systems. For the operations that are snake oil, better solutions exist- including "cp /dev/{urandom,zero} ...", along with pv/pipemeter for a progress bar.

Good question Andreas.

I suppose that for seeking this bug to be fixed in the current wipe tool shipped with the distribution it would be more useful for me to try to revive discussion in the referenced upstream bug and maybe even contribute a patch there. However, I am posting here to open discussion about what the openSUSE community thinks is the best way forward. Options include

 * Removing the tool from the distribution as it does not function correctly

 * Replacing the tool with a working tool with the same command name and that supports all its command line options

 * Replacing the tool with a working tool with a different command line and possibly incompatible command line options

 * Replacing the tool with a non-functional tool with the same command name that only prints instructions how to wipe files and devices manually and returns an error code

 * Patching the upstream tool

 * Implementing a new tool from scratch with the same command name and that supports all its command line options

Current version 2.3.1 of the wipe tool has 4076 lines of C code. Reading wipe's man page, I think a re-implementation in Python would be much shorter and more easily maintained. Files can be opened with O_SYNC also in Python and the MT PRNG is natively available. I don't understand though the sentence about using the "mand" mount option, or why file locking would be desirable at all during wiping.

the modern replacement is the `shred` tool (standard part of coreutils).

Hi Joachim, would you please have a try whether the replacement tool of `shred` work? Thanks.

The progress output of `shred -n 1 -v` on a device of similar size looks right. See below.

Still, something needs to be done about `wipe`, e.g. wrapping it in a 3-line script that outputs a warning message that it is not working for large files (and then runs the command with the supplied args) or removing the package altogether.


``` shell
IMG=test2tb-nocow.img
GiB=2048
BYTES=$((1024*1024*1024*GiB))
touch $IMG
chattr +C $IMG
fallocate -l $BYTES $IMG
losetup --find --show test2tb-nocow.img
shred -n 1 -v /dev/loop0
```

Output after 5 minutes (RAID 10 on 4 HDDs):
`shred: /dev/loop0: pass 1/1 (random)...90GiB/2.0TiB 4%`

This matches the expected speed and progress.

Or we just stop shipping the obsolete stuff

Yes, removing the tool was option 1 of comment 2.

Clearing "needinfo" as I assume this is for "does shred work?".

For the user experience of a user looking to install "wipe" as they read somewhere they should use it, just not having it in the repo is not great either. It would be nice to get a search result with an explanation why the tool is not available and what the recommended replacement is. Could there be a package that doesn't install any files and only displays some info on stdout and, before install, in the package's description field?

We could just have the shred package provide and obsolete wipe.

Shred is missing some functionality to emulate wipe. Most likely to be missed by users, I think, will be -r (recursive) and -i (interactive). Default with -r is to skip special files (-N). That's also not supported by shred, which assumes the user specifies each file individually and only the intended files.

Sure, a script can also emulate -r, -N and -i but then we are doing more programming than just mapping command line options. If we don't support those (and print an error message instead), we are getting close to option 4 of comment 2 (print instructions and exit).

(In reply to Joachim Wagner from comment #9)
> Shred is missing some functionality to emulate wipe. Most likely to be
> missed by users, I think, will be -r (recursive) and -i (interactive).
> Default with -r is to skip special files (-N). That's also not supported by
> shred, which assumes the user specifies each file individually and only the
> intended files.

It will certainly not match one to one (unless someone contributes to upstream wipe and fix the pending issues, or to shred to add the missing ones).

While this doesn't work "out of the box" without a helper script, all the above missing functionality can be easily replaced by something like:

> find /path -type f -ok shred {} \;

Certainly it is not a lot of work but clearly more work than replying here.

If I tried it as a shell script, it would look horrible as my shell scripting skills are just good enough to make it work.

Would Python be acceptable for a system tool like this? I'd be doing a much better job in Python and I see that there is at least one other system tool using Python: bcache-status. (See also bug 1216370.)

(In reply to Joachim Wagner from comment #11)
> Certainly it is not a lot of work but clearly more work than replying here.
> 
> If I tried it as a shell script, it would look horrible as my shell
> scripting skills are just good enough to make it work.
> 
> Would Python be acceptable for a system tool like this? I'd be doing a much
> better job in Python and I see that there is at least one other system tool
> using Python: bcache-status. (See also bug 1216370.)

In general I think it would be good to minimize dependencies especially in the base system.

I don't think I have any better recommendation than comment #8.

The `wipe` tool appears unmaintained for over a decade now, and there may be bigger problems lurking. I would recommend making it obsolete instead of continuing to artificially support it, and giving to the users the illusion that this is being maintained. Users of `wipe` should have been moved to `shred` a long time ago.

If there is such desire to keep any of wipe features or interface compatibility, the best way would be to contribute to upstream coreutils/shred directly.