This file is indexed.

/usr/share/doc/libgsecuredelete0/TODO is in libgsecuredelete0 0.2.1-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
'*' means important things, '+' means cool things, '-' means things that might
be done.
FIXMEs are things that needs to be fixed (the code is here but needs fixing);
TODOs are things that needs to be created (there is no code for them):
There are some FIMXE/TODO in the code that are not listed here: it could be
either a mess or a code-specific thing that is not important enough or too
specific to be listed here.

See result of `rgrep FIXME gsecuredelete` and `rgrep TODO gsecuredelete` too.


FIXMEs:
+ Better design for the arguments, allowing subclasses not to need to add
  parent's supported arguments themselves.

+ Get the pass number reported by the program rather than guessing it.
  (gsecuredelete/securedelete-operation.vala:88).
  Not sure it is useful or really cleanly doable.

? (SwapOperation) is /proc/swaps a good method to know if a swap device is in
  use?
  Neither sure it is wrong to read /proc/swaps nor the swap wiping is supported
  in practice on non-Linux OS.


TODOs:
* Test MemOperation (gsecuredelete/mem-operation.vala:23).
  This needs a courageous user! (Having a small amount of memory is probably
  better as this operation may be slow (as the manual of smem says)).

* Replace this library by a libscrub-based one.  secure-delete is unmaintained,
  has bugs (like the one `gsd-sfill-helper` works around) and is based on a
  nearly obsolescent wiping algorithm.  Scrub on the other hand is maintained,
  has less bugs and supports various kind of wiping patters appropriate for
  today's hardware.

+ Add a "message" argument to the progress callback with the (possibly empty)
  progress message?

+ Be able to work as another user? (gsecuredelete/async-operation.vala:40)
  find informations about this issue and what can/could/should be done to
  fix it.
  Perhaps it is not the library that should provide the functionality but
  the caller program that may grant its rights or so, don't know.

+ Use `truncate` rather than `dd` to create large files in the sfill wrapper
  (gsd-sfill-helper) since they will be securely deleted anyway.  This would
  make things faster by getting rid of a first extra (and unwanted) pass.

- Support for canonical names/paths. (gsecuredelete/delete-operation.vala:66)
  This affects all operations using paths, but in first place DeleteOperation
  that supports adding/removing of deletion targets.