non-interactive duplicity job using GPG keys crashes

[Joshua Jensen]

I'm running a duplicity nightly backup from cron that is having problems. I'm using a GPG keypair. The public key is used to encrypt without a PASSPHRASE or interaction, and the private key to decrypt and restore interactively with a PASSPHRASE later if necessary.

This works from my command prompt *where I am not prompted for anything when running this command*.

However, from cron, this fails with getpass.py being uncomfortable about not being able to control echo on the terminal:

ARGS="--asynchronous-upload --tempdir /tmp --no-print-statistics \
 --include /data/backups/bin --encrypt-key CE71E9DC \
 --exclude-globbing-filelist $DEST/bin/rdiff-backup-excludes \
 -v2 --volsize 100 $@"

duplicity $ARGS / file://$DESTDIR

/usr/lib64/python2.6/getpass.py:83: GetPassWarning: Can not control echo on the terminal.
  passwd = fallback_getpass(prompt, stream)
Warning: Password input may be echoed.
GnuPG passphrase: Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1245, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1238, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1139, in main
    sync_archive()
  File "/usr/bin/duplicity", line 949, in sync_archive
    globals.gpg_profile.passphrase = get_passphrase(1, "sync")
  File "/usr/bin/duplicity", line 129, in get_passphrase
    pass1 = getpass.getpass("GnuPG passphrase: ")
  File "/usr/lib64/python2.6/getpass.py", line 83, in unix_getpass
    passwd = fallback_getpass(prompt, stream)
  File "/usr/lib64/python2.6/getpass.py", line 118, in fallback_getpass
    return _raw_input(prompt, stream)
  File "/usr/lib64/python2.6/getpass.py", line 135, in _raw_input
    raise EOFError
EOFError

duplicity version 0.6.11, Python 2.6.5, RHEL 6.0 x86_64, target filesystem is an NFS mount

Surely non-interactive duplicity commands shouldn't fail because duplicity can't go interactive!!

[Kenneth Loafman (kenneth-loafman)]

Duplicity requires a password-less key pair for backup. It needs to decrypt
the manifest to compare the local cache against the remote store. This is a
known limitation.

...Ken

On Mon, Apr 11, 2011 at 4:00 PM, Joshua Jensen <email address hidden>wrote:

> Public bug reported:
>
> I'm running a duplicity nightly backup from cron that is having
> problems. I'm using a GPG keypair. The public key is used to encrypt
> without a PASSPHRASE or interaction, and the private key to decrypt and
> restore interactively with a PASSPHRASE later if necessary.
>
> This works from my command prompt *where I am not prompted for anything
> when running this command*.
>
> However, from cron, this fails with getpass.py being uncomfortable about
> not being able to control echo on the terminal:
>
> ARGS="--asynchronous-upload --tempdir /tmp --no-print-statistics \
> --include /data/backups/bin --encrypt-key CE71E9DC \
> --exclude-globbing-filelist $DEST/bin/rdiff-backup-excludes \
> -v2 --volsize 100 $@"
>
> duplicity $ARGS / file://$DESTDIR
>
>
> /usr/lib64/python2.6/getpass.py:83: GetPassWarning: Can not control echo on
> the terminal.
> passwd = fallback_getpass(prompt, stream)
> Warning: Password input may be echoed.
> GnuPG passphrase: Traceback (most recent call last):
> File "/usr/bin/duplicity", line 1245, in <module>
> with_tempdir(main)
> File "/usr/bin/duplicity", line 1238, in with_tempdir
> fn()
> File "/usr/bin/duplicity", line 1139, in main
> sync_archive()
> File "/usr/bin/duplicity", line 949, in sync_archive
> globals.gpg_profile.passphrase = get_passphrase(1, "sync")
> File "/usr/bin/duplicity", line 129, in get_passphrase
> pass1 = getpass.getpass("GnuPG passphrase: ")
> File "/usr/lib64/python2.6/getpass.py", line 83, in unix_getpass
> passwd = fallback_getpass(prompt, stream)
> File "/usr/lib64/python2.6/getpass.py", line 118, in fallback_getpass
> return _raw_input(prompt, stream)
> File "/usr/lib64/python2.6/getpass.py", line 135, in _raw_input
> raise EOFError
> EOFError
>
> duplicity version 0.6.11, Python 2.6.5, RHEL 6.0 x86_64, target
> filesystem is an NFS mount
>
>
> Surely non-interactive duplicity commands shouldn't fail because
> duplicity can't go interactive!!
>
> ** Affects: duplicity
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/758077
>
> Title:
> non-interactive duplicity job using GPG keys crashes
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> I'm running a duplicity nightly backup from cron that is having
> problems. I'm using a GPG keypair. The public key is used to encrypt
> without a PASSPHRASE or interaction, and the private key to decrypt
> and restore interactively with a PASSPHRASE later if necessary.
>
> This works from my command prompt *where I am not prompted for
> anything when running this command*.
>
> However, from cron, this fails with getpass.py being uncomfortable
> about not being able to control echo on the terminal:
>
> ARGS="--asynchronous-upload --tempdi...

[Joshua Jensen (joshua-joshuajensen)]

Strange. That makes sense, but I don't that your point addresses my bug. The problem isn't that it can't ask for a PASSPHRASE... remember, it *ISN'T* asking for one when I run this buy hand. I don't have PASSPHRASE set as an environment variable or anything, it simply doesn't need one to create an incremental archive.

I think instead my bug is that PASSPHRASE doesn't exist, and getpass.py tries to at least be able to read from an interactive prompt... not that it needs to or does, but that it doesn't like the non-interactive prompt.

I'll experiment with 'export PASSPHRASE=""' in my script and see if that changes its behavior.

[Joshua Jensen (joshua-joshuajensen)]

That doesn't seem to work. I can't explain why the PASSPHRASE isn't needed, other than if the cache is intact that perhaps duplicity doesn't need to update it, and therefor doesn't need the PASSPHRASE to unlock the secret key.

[Steffen (steffen-weber)]

Had the same problem. Solution: Ensure that in your /etc/crontab you set the environment variable $HOME to the home directory of the user that executes the cronjob. Because otherwise:

1) Duplicity won't be able to find it's archive directory and as a consequence duplicity will fetch the encrypted metadata from remote and needs your private key to decrypt the metadata. (Alternatively use duplicity's "--archive-dir" option.)

2) Additionally, without a correct $HOME environment variable, duplicity will use the wrong ~/.gnupg directory and therefore cannot find your public/private keys. (I don't know any workaround here, just set $HOME correctly. :))

[Kenneth Loafman (kenneth-loafman)]

I usually do this in my crontab:
   sudo -u ken -i duplicity ...

--
Sent from my Droid.
On May 4, 2011 9:06 AM, "Steffen" <email address hidden> wrote:
> Had the same problem. Solution: Ensure that in your /etc/crontab you set
> the environment variable $HOME to the home directory of the user that
> executes the cronjob. Because otherwise:
>
> 1) Duplicity won't be able to find it's archive directory and as a
> consequence duplicity will fetch the encrypted metadata from remote and
> needs your private key to decrypt the metadata. (Alternatively use
> duplicity's "--archive-dir" option.)
>
> 2) Additionally, without a correct $HOME environment variable, duplicity
> will use the wrong ~/.gnupg directory and therefore cannot find your
> public/private keys. (I don't know any workaround here, just set $HOME
> correctly. :))
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/758077
>
> Title:
> non-interactive duplicity job using GPG keys crashes
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> I'm running a duplicity nightly backup from cron that is having
> problems. I'm using a GPG keypair. The public key is used to encrypt
> without a PASSPHRASE or interaction, and the private key to decrypt
> and restore interactively with a PASSPHRASE later if necessary.
>
> This works from my command prompt *where I am not prompted for
> anything when running this command*.
>
> However, from cron, this fails with getpass.py being uncomfortable
> about not being able to control echo on the terminal:
>
> ARGS="--asynchronous-upload --tempdir /tmp --no-print-statistics \
> --include /data/backups/bin --encrypt-key CE71E9DC \
> --exclude-globbing-filelist $DEST/bin/rdiff-backup-excludes \
> -v2 --volsize 100 $@"
>
> duplicity $ARGS / file://$DESTDIR
>
>
> /usr/lib64/python2.6/getpass.py:83: GetPassWarning: Can not control echo
on the terminal.
> passwd = fallback_getpass(prompt, stream)
> Warning: Password input may be echoed.
> GnuPG passphrase: Traceback (most recent call last):
> File "/usr/bin/duplicity", line 1245, in <module>
> with_tempdir(main)
> File "/usr/bin/duplicity", line 1238, in with_tempdir
> fn()
> File "/usr/bin/duplicity", line 1139, in main
> sync_archive()
> File "/usr/bin/duplicity", line 949, in sync_archive
> globals.gpg_profile.passphrase = get_passphrase(1, "sync")
> File "/usr/bin/duplicity", line 129, in get_passphrase
> pass1 = getpass.getpass("GnuPG passphrase: ")
> File "/usr/lib64/python2.6/getpass.py", line 83, in unix_getpass
> passwd = fallback_getpass(prompt, stream)
> File "/usr/lib64/python2.6/getpass.py", line 118, in fallback_getpass
> return _raw_input(prompt, stream)
> File "/usr/lib64/python2.6/getpass.py", line 135, in _raw_input
> raise EOFError
> EOFError
>
> duplicity version 0.6.11, Python 2.6.5, RHEL 6.0 x86_64, target
> filesystem is an NFS mount
>
>
>
> Surely non-interactive duplicity commands shouldn't fail because duplicity
can't go interactive!!