--gpg-binary only works if gpg is in PATH

[David Tucker]

I installed duplicity 0.8.10 (Python 3.8) via Homebrew on MacOS 10.13.6,
and I have to add the --gpg-binary parent to PATH in order to call duplicity from cron.

$ PATH= /usr/local/bin/duplicity --gpg-binary /usr/local/bin/gpg --help
Traceback (innermost last):
  File "/usr/local/bin/duplicity", line 100, in <module>
    with_tempdir(main)
  File "/usr/local/bin/duplicity", line 86, in with_tempdir
    fn()
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/lib/python3.8/site-packages/duplicity/dup_main.py", line 1525, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/lib/python3.8/site-packages/duplicity/commandline.py", line 1136, in ProcessCommandLine
    globals.gpg_profile = gpg.GPGProfile()
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/lib/python3.8/site-packages/duplicity/gpg.py", line 95, in __init__
    self.gpg_version = self.get_gpg_version(globals.gpg_binary)
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/lib/python3.8/site-packages/duplicity/gpg.py", line 111, in get_gpg_version
    res = gnupg.run([u"--version"], create_fhs=[u"stdout"])
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/lib/python3.8/site-packages/duplicity/gpginterface.py", line 374, in run
    process = self._attach_fork_exec(gnupg_commands, args,
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/lib/python3.8/site-packages/duplicity/gpginterface.py", line 427, in _attach_fork_exec
    self._as_child(process, gnupg_commands, args)
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/lib/python3.8/site-packages/duplicity/gpginterface.py", line 466, in _as_child
    os.execvp(command[0], command)
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/bin/../lib/python3.8/os.py", line 566, in execvp
    _execvpe(file, args)
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/bin/../lib/python3.8/os.py", line 608, in _execvpe
    raise last_exc
  File "/usr/local/Cellar/duplicity/0.8.10/libexec/bin/../lib/python3.8/os.py", line 599, in _execvpe
    exec_func(fullname, *argrest)
 FileNotFoundError: [Errno 2] No such file or directory

GPGError: failed to determine gnupg version of None from b''

This works:
$ PATH=/usr/local/bin /usr/local/bin/duplicity --gpg-binary /usr/local/bin/gpg --help

[David Tucker (dmtucker)]

Related (older repro): https://github.com/henrysher/duplicity/issues/17

[Kenneth Loafman (kenneth-loafman)]

/usr/local/bin/gpg@ -> ../Cellar/gnupg/2.2.19/bin/gpg

You need --gpg-binary=/usr/local/Cellar/gnupg/2.2.19/bin/gpg

IOW, resolve the symlinks.

Better yet, use PATH= in your cron file.

[David Tucker (dmtucker)]

I'm not sure I follow...

PATH= /usr/local/bin/duplicity --gpg-binary /usr/local/Cellar/gnupg/2.2.19/bin/gpg --help

That still reproduces for me.

[Kenneth Loafman (kenneth-loafman)]

duplicity does not process options if --help is in the command line.

At the top of your crontab put PATH, then you won't need the --gpg-binary option, like so:

PATH=/usr/local/bin:/usr/local/sbin:$PATH

0 * * * * duplicity /Users file:///tmp/testdup

[David Tucker (dmtucker)]

Interesting... So I only used --help to simplify things.
I originally reproduced this in a real invocation (--full-if-older-than 1W + GPG args).

Here is an example where I put the wrong gpg on $PATH, and duplicity tries to use that instead of --gpg-binary with an invocation of list-current-files:

$ tree
.
└── bin
    └── gpg

1 directory, 1 file
$ cat bin/gpg
#!/usr/local/bin/bash
echo WRONG GPG!!!!!
$ PATH=bin /usr/local/bin/duplicity --gpg-binary /usr/local/Cellar/gnupg/2.2.19/bin/gpg --encrypt-key "$encrypt_key" --sign-key "$sign_key" list-current-files scp://<email address hidden>/dir/path
GPGError: failed to determine gnupg version of None from b'WRONG GPG!!!!!'

When does --gpg-binary take effect?

[Kenneth Loafman (kenneth-loafman)]

It turns out that --gpg-binary is probably the only one like this that will cause problems. duplicity looks for the 'default' gpg version to fill in the gpg profile which command line processing then proceeds to fill in. Going have to move things around some to fix this.

BTW, why run with no PATH under cron when you can have a PATH statement? I'm sure you'll encounter other items not on the PATH once we get past this issue.

[David Tucker (dmtucker)]

I didn't actually know you could set PATH in a crontab until you mentioned it :p

Setting PATH is effectively what I've been doing as a workaround (just, in my backup script instead of in the cron config). My initial approach was to just use absolute paths to all my binaries, and that has pretty much worked (though, it's certainly more annoying).

[Kenneth Loafman (kenneth-loafman)]

$ man 5 crontab
$ man crontab

Both are good resources.

I'm going to mark this invalid again. The fix is invasive and this is really an edge case.

[David Tucker (dmtucker)]

That's probably ok, esp. since there's a workaround.
Thanks for taking a look!

(side note: seems more like wontfix than invalid?)