Bug 1019179

Summary: wipe: fix incomplete file name overwriting
Product: [Fedora] Fedora Reporter: Till Maas <opensource>
Component: wipeAssignee: Scott Henson <scott>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: opensource, scott
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 17:41:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Till Maas 2013-10-15 09:13:23 UTC
Description of problem:
Please consider to apply this path that fixes overwriting of file names:
https://github.com/berke/wipe/pull/2

Additional info:
The patch is against upstream version 0.22, which is missing in Fedora.

If you do not have the time to update wipe, I can do it as provenpackager. I will also fix the URL as reported in a separated bug and perform some minor SPEC cleanups.

Here is a copy of a more detailed bug report from Debians bugtracker. The bug does not yet have a bug number:
Package: wipe
Version: 0.22-1
Severity: normal
Tags: upstream patch

The wipe man-page states:
"Normally, wipe tries to cover file names by renaming them"

However, this does not work for me for different versions of wipe.
Using fls from the sleuthkit, its easy to see the name of the wiped file
in the filesystem on the ext{2,3,4} filesystems. On vfat, btrfs and xfs
the filename can be retrieved easily, too.

My testcase was:
$ dd if=/dev/zero bs=1M count=256 of=wipeimagefile-ext2.bin;
$ losetup /dev/loop2 wipeimagefile-ext2.bin;
$ mkfs.ext2 /dev/loop2;
$ mkdir /mnt/wipetest;
$ mount /dev/loop2 /mnt/wipetest;
$ echo "very secret data that should be deleted after use" > /mnt/wipetest/secretfile.txt;
$ wipe -fc /mnt/wipetest/secretfile.txt;
$ umount /mnt/wipetest;
$ losetup -d /dev/loop2;
$ rmdir /mnt/wipetest;
$ fls wipeimagefile-ext2.bin
  wipeimagefile-ext2.bin
  d/d 11: lost+found
  r/- * 0:        secretfile.txt
  r/- * 0:        4hv06IB9SyTgVt
  d/d 2561:       $OrphanFiles

In contrast to this behaviour, shred from coreutils-8.5 succeeds in
hiding the filenames. shred was used with the parameters -fu for this
comparison.

I believe that this is from the different usage of sync() in wipe and
fsync(dir_fd, dirname) in shred.

Note that this isn't a limitation of the filesystem or the operating
system, as shred succeeds in hiding the original filename.

Used for the test were the following versions of wipe:
wipe-0.21-9 from debian squeeze,
wipe-0.22-1 from debian wheezy and sid,
wipe-0.21-5.fc15 from fedora 15,
wipe-0.21-8.fc19 from fedora 19
on ext2, ext3, ext4, vfat, xfs and btrfs.

I have written a patch that fixes the mentioned issue.
It is heavily based on the source of shred from coreutils by Colin Plumb.
While shred is now licensed under GPLv3, the parts of my patch that were
derived from shred could easily be changed to a version of shred
(git cad884a..) that was licensed under GPLv2.

For the same testcase as written in my first mail, the fls output is:
d/d 11: lost+found
r/- * 0:        0
r/- * 0:        00
d/d 2561:       $OrphanFiles

Note that this patch only keeps the filename from being readable in the
filesystem structure. For journaling fileystems, such as ext{3,4}, the
filename is still retained in the journal.

Comment 1 Till Maas 2013-10-15 09:14:35 UTC
Please respond here, otherwise I will start the non-responsive maintainer procedure, since other bug reports were not commented by you.

Comment 2 Till Maas 2013-10-22 16:26:40 UTC
7 days passsed since comment:1, please respond accordingto the non-responsive maintainer procedure:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Comment 3 Till Maas 2013-10-30 09:41:00 UTC
8 more days passed since comment:2,  please respond according to the non-responsive maintainer procedure:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Comment 4 Fedora End Of Life 2015-01-09 20:15:37 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Fedora End Of Life 2015-02-17 17:41:26 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.