duplicity-team team mailing list archive

[Eugene Crosser <504423@xxxxxxxxxxxxxxxxxx>]

I would argue that exposing the password in an environment variable is
almost as bad as in the command line ("it's safe on most platforms" is
not good enough).

I cannot suggest a solution that would work well for all backends... It
might be useful to have a separate method to provide the password by
giving duplicity the filename that contains it. E.g. via a different
environment variable, or via a command-line option ("duplicity
--pwdfile=/etc/backuppwd ..."). However this won't help if the backend
is a separate executable and has to have the password in the command
line or environment variable - it will still be exposed via /proc. For
builtin backends, this looks like a decently good solution.

-- 
You received this bug notification because you are a member of
duplicity-team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/504423

Title:
  duplicity shows sensitive data in process listing

Status in Duplicity - Bandwidth Efficient Encrypted Backup:
  Confirmed

Bug description:
  If credentials are given in the command line url parameter these show
  up in 'ps'

  e.g.

  /usr/bin/duplicity --verbosity 4 --encrypt-key FD3846C2 --sign-key
  FD3846C2 --gpg-options= --exclude-globbing-filelist
  /root/.duply/bkp/exclude /backup/
  ftp://<user>:<PASSWORT>@<backupserver>/backup

  suggestion is to introduce env vars URL_PASSWORD/URL_USERNAME and to
  keep FTP_PASSWORD for ftp backend only and backward compatibility. The
  fact that FTP_PASSWORD can be used with nearly all backend is afaik
  not documented. Even so duply 1.5.1.4+ will use it until this bug is
  resolved.

  for the future a config file based auth as mentioned in
  http://lists.gnu.org/archive/html/duplicity-talk/2010-01/msg00032.html
  could make sense.

  .. ede

To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/504423/+subscriptions