[Pkg-privacy-commits] [libgsecuredelete] 39/168: Added a TODO-list with the current issues.

[Ulrike Uhlig]

This is an automated email from the git hooks/post-receive script.

u-guest pushed a commit to branch master
in repository libgsecuredelete.

commit 763176543a813ad7f3d481f849889ddef381e382
Author: Colomban Wendling <ban at herbesfolles.org>
Date:   Sat Oct 17 03:55:31 2009 +0200

    Added a TODO-list with the current issues.
---
 TODO | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/TODO b/TODO
new file mode 100644
index 0000000..8da478d
--- /dev/null
+++ b/TODO
@@ -0,0 +1,57 @@
+'*' 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:
+* Do NOT use search path for launching commands
+  (gsecuredelete/securedelete-operation.vala:24).
+  This is a SECURITY VULNERABILITY if the PATH (or the system default
+  search path, or whatever used to find a command) used by a program with
+  great rights using this library was tuned by a malicious user (or if the
+  owner of the great rights is stupid, but for this we can't do anything).
+  The vulnerability occurs if a user may modify the PATH used to search
+  for the spawned commands of another user (and maybe root): this malicious
+  user may then create its own command that gets launched in place of the
+  expected one, with the launcher's rights.
+  Of course, it should not happens in a perfect environment with prefect
+  users, but this library is not only meant for Heaven.
+  .
+  An easy fix for this is to hardcode the command's path to something like
+  /bin/<command> or another highly standard path, but this is not flexible.
+  A better fix would be to use a user-specified command (and prehaps fall
+  back to a hardcoded default if none found) through a configuration file.
+  Even more better would be to have a system-wide configuration file
+  (something like a configuration file in /etc or so) and per-user ones,
+  allowing each user to use its own tools if needed/wanted.
+
++ 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-Linus 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)).
+
++ 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 functionnality but
+  the caller program that may grant its rights or so, don't know.
+
+- 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.

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-privacy/packages/libgsecuredelete.git