Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#880111: duplicity: fails to ask for GPG key passphrase and claims that none was given
102 views
Skip to first unread message
Francesco Poli (wintermute)
Oct 29, 2017, 12:10:03 PM10/29/17
to
Package: duplicity
Version: 0.7.14-1
Severity: important
Hello and thanks for maintaining duplicity in Debian.
I have experienced a new issue with duplicity for some weeks and I do
not understand what's going on.
When I backup my user data with duplicity, I do not have any X graphical
session open.
The command issued on the text console is:
$ duplicity --encrypt-key XXXXXXXXXXXXXXXX \
--full-if-older-than 30D \
--include-filelist .duplicity.include . file://backup
When doing so, duplicity (or maybe gpg) complains that it could not
perform any decryption, since no passphrase was given:
===== Begin GnuPG log =====
gpg: encrypted with XXXX-bit XXX key, ID 0xXXXXXXXXXXXXXXXX, created XXXX-XX-XX
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
gpg: public key decryption failed: No passphrase given
gpg: decryption failed: No secret key
===== End GnuPG log =====
After that, duplicity seems to go on and to correctly perform the backup
(at least, it says 0 errors and the statistics output looks OK).
However, at each backup, I see the above quoted error message.
The point is: no passphrase was ever asked for, hence no wonder
no passphrase was given!
At first I thought that I needed a pinentry-* package for non-graphical
environments: I only had pinentry-gtk2 installed.
Hence I installed pinentry-tty:
$ aptitude search pinentry | grep ^i
i A pinentry-gtk2 - GTK+-2-based PIN or pass-phrase entry dialog for GnuPG
i pinentry-tty - minimal dumb-terminal PIN or pass-phrase entry for GnuPG
But the issue persists.
I tried to restore one file from my backup (from inside an X graphical
session) and it seems to work correctly: it asks for the GPG key passphrase
(on the terminal emulator) and successfully restore a file identical to
the original.
$ duplicity restore --file-to-restore tmp/foo file://backup Downloads/foo
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sun Oct 8 01:06:24 2017
GnuPG passphrase for decryption:
$ diff -sq tmp/foo Downloads/foo
Files tmp/foo and Downloads/foo are identical
However, when performing backups, duplicity seems to be unable to ask
for the passphrase.
Please note that this bug is similar to #565398, but the symptoms are
different in my case. I do not have a non-English locale:
$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
What's going on?
Is there anything I failed to understand?
Please let me know.
Thanks for your time!
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages duplicity depends on:
ii gnupg 2.2.1-4
ii libc6 2.24-17
ii librsync1 0.9.7-10+b1
ii python 2.7.14-1
ii python-fasteners 0.12.0-3
ii python-lockfile 1:0.12.2-2
Versions of packages duplicity recommends:
ii python-oauthlib 2.0.4-1
ii python-paramiko 2.0.0-1
ii python-pexpect 4.2.1-1
ii python-urllib3 1.21.1-1
ii rsync 3.1.2-2
Versions of packages duplicity suggests:
pn lftp <none>
pn ncftp <none>
pn python-boto <none>
pn python-cloudfiles <none>
pn python-gdata <none>
pn python-swiftclient <none>
pn tahoe-lafs <none>
-- no debconf information
Version: 0.7.14-1
Severity: important
Hello and thanks for maintaining duplicity in Debian.
I have experienced a new issue with duplicity for some weeks and I do
not understand what's going on.
When I backup my user data with duplicity, I do not have any X graphical
session open.
The command issued on the text console is:
$ duplicity --encrypt-key XXXXXXXXXXXXXXXX \
--full-if-older-than 30D \
--include-filelist .duplicity.include . file://backup
When doing so, duplicity (or maybe gpg) complains that it could not
perform any decryption, since no passphrase was given:
===== Begin GnuPG log =====
gpg: encrypted with XXXX-bit XXX key, ID 0xXXXXXXXXXXXXXXXX, created XXXX-XX-XX
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
gpg: public key decryption failed: No passphrase given
gpg: decryption failed: No secret key
===== End GnuPG log =====
After that, duplicity seems to go on and to correctly perform the backup
(at least, it says 0 errors and the statistics output looks OK).
However, at each backup, I see the above quoted error message.
The point is: no passphrase was ever asked for, hence no wonder
no passphrase was given!
At first I thought that I needed a pinentry-* package for non-graphical
environments: I only had pinentry-gtk2 installed.
Hence I installed pinentry-tty:
$ aptitude search pinentry | grep ^i
i A pinentry-gtk2 - GTK+-2-based PIN or pass-phrase entry dialog for GnuPG
i pinentry-tty - minimal dumb-terminal PIN or pass-phrase entry for GnuPG
But the issue persists.
I tried to restore one file from my backup (from inside an X graphical
session) and it seems to work correctly: it asks for the GPG key passphrase
(on the terminal emulator) and successfully restore a file identical to
the original.
$ duplicity restore --file-to-restore tmp/foo file://backup Downloads/foo
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sun Oct 8 01:06:24 2017
GnuPG passphrase for decryption:
$ diff -sq tmp/foo Downloads/foo
Files tmp/foo and Downloads/foo are identical
However, when performing backups, duplicity seems to be unable to ask
for the passphrase.
Please note that this bug is similar to #565398, but the symptoms are
different in my case. I do not have a non-English locale:
$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
What's going on?
Is there anything I failed to understand?
Please let me know.
Thanks for your time!
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages duplicity depends on:
ii gnupg 2.2.1-4
ii libc6 2.24-17
ii librsync1 0.9.7-10+b1
ii python 2.7.14-1
ii python-fasteners 0.12.0-3
ii python-lockfile 1:0.12.2-2
Versions of packages duplicity recommends:
ii python-oauthlib 2.0.4-1
ii python-paramiko 2.0.0-1
ii python-pexpect 4.2.1-1
ii python-urllib3 1.21.1-1
ii rsync 3.1.2-2
Versions of packages duplicity suggests:
pn lftp <none>
pn ncftp <none>
pn python-boto <none>
pn python-cloudfiles <none>
pn python-gdata <none>
pn python-swiftclient <none>
pn tahoe-lafs <none>
-- no debconf information
Alexander Zangerl
Oct 31, 2017, 8:10:02 AM10/31/17
to
tags 880111 + moreinfo
severity 880111 normal
thanks
On Sun, 29 Oct 2017 16:38:10 +0100, "Francesco Poli (wintermute)" writes:
>When doing so, duplicity (or maybe gpg) complains that it could not
>perform any decryption, since no passphrase was given:
hmm. i suspect the interaction of gpg v2.2, the gnupg-agent and
some leftover/broken data in the local cache
that duplicity thinks it needs to to decrypt before doing its backup job.
as far as i'm aware, the local manifest/cache is the only thing
which duplicity possibly needs to decrypt, given your encrypt-only
command line.
>I tried to restore one file from my backup (from inside an X graphical
>session) and it seems to work correctly: it asks for the GPG key passphrase
>(on the terminal emulator) and successfully restore a file identical to
>the original.
ok, good, that confirms that at least the core functionality works.
>Please note that this bug is similar to #565398,
yes, superficially similar - but debian's duplicity has ignored locales
as a workaround for this bug for a long time now; that's most certainly not it.
>Is there anything I failed to understand?
not that i'm aware of; you're using duplicity pretty much like i
do myself, except that i've decided to stay with gpg v1 for a while
longer (b/c i dislike the gnupg-vs-agent architecture).
a few things might helpful for further diagnostics/triage:
1. what does collection-status report?
does that also attempt to decrypt something and fail?
does a cleanup improve matters?
2. could you run another backup invocation with -v9 and attach the output?
feel free to blank your keyid and other sensitives; the
remaining fine print of what is being attempted when/why would be helpful.
3. does a totally new backup to a different location, with an
empty/new .cache/duplicity directory work?
(alternative to nuking cache: --archive-dir <somewhere> in the invocation)
4. does your gnupg config contain anything special that might
interfere with --pinentry-mode=loopback?
most specifically, does your agent config contain
anything like no-allow-loopback-pinentry?
5. does duplicity work correctly if you run it with --use-agent?
see --use-agent in man duplicity; this directly affects who might
ask for a passphrase, duplicity or gpg-agent.
6. does the duplicity backup work if you run it from X?
7. does gnupg sign work if you run it from a non-X console,
like where your failing duplicity was run?
regards
az
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, Halflife-Server:
Server, der nur halb lebt. Kurz: IIS. -- Andreas Dau
severity 880111 normal
thanks
On Sun, 29 Oct 2017 16:38:10 +0100, "Francesco Poli (wintermute)" writes:
>When doing so, duplicity (or maybe gpg) complains that it could not
>perform any decryption, since no passphrase was given:
some leftover/broken data in the local cache
that duplicity thinks it needs to to decrypt before doing its backup job.
as far as i'm aware, the local manifest/cache is the only thing
which duplicity possibly needs to decrypt, given your encrypt-only
command line.
>I tried to restore one file from my backup (from inside an X graphical
>session) and it seems to work correctly: it asks for the GPG key passphrase
>(on the terminal emulator) and successfully restore a file identical to
>the original.
>Please note that this bug is similar to #565398,
as a workaround for this bug for a long time now; that's most certainly not it.
>Is there anything I failed to understand?
do myself, except that i've decided to stay with gpg v1 for a while
longer (b/c i dislike the gnupg-vs-agent architecture).
a few things might helpful for further diagnostics/triage:
1. what does collection-status report?
does that also attempt to decrypt something and fail?
does a cleanup improve matters?
2. could you run another backup invocation with -v9 and attach the output?
feel free to blank your keyid and other sensitives; the
remaining fine print of what is being attempted when/why would be helpful.
3. does a totally new backup to a different location, with an
empty/new .cache/duplicity directory work?
(alternative to nuking cache: --archive-dir <somewhere> in the invocation)
4. does your gnupg config contain anything special that might
interfere with --pinentry-mode=loopback?
most specifically, does your agent config contain
anything like no-allow-loopback-pinentry?
5. does duplicity work correctly if you run it with --use-agent?
see --use-agent in man duplicity; this directly affects who might
ask for a passphrase, duplicity or gpg-agent.
6. does the duplicity backup work if you run it from X?
7. does gnupg sign work if you run it from a non-X console,
like where your failing duplicity was run?
regards
az
--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Fachbegriffe der Informatik, Halflife-Server:
Server, der nur halb lebt. Kurz: IIS. -- Andreas Dau
Alexander Zangerl
Nov 3, 2017, 4:10:02 AM11/3/17
to
retitle 880111 duplicity should log a warning (not error) for encrypted manifest
severity 880111 minor
tags 880111 - moreinfo
thanks
On Wed, 01 Nov 2017 20:19:31 +0100, Francesco Poli writes:
>> 2. could you run another backup invocation with -v9 and attach the output?
...
>Attached as duplicity.out
thanks for your diagnostic data.
>I cannot spot the error there, though... :-|
yes, there is no problem in that run.
in the meantime i've started up a blank unstable chroot, and i can
reproduce the issue on incremental backups.
exec summary: please ignore that error message.
i've checked the source, and this is actually working as designed:
upstream changed the handling of remote manifests in 0.7.14
to more-or-less blindly attempt to access an encrypted remote manifest
and if unsuccessful, log that as a nonfatal 'error'.
http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/revision/1252/duplicity/collections.py
as far as i can tell duplicity doesn't even attempt to fully interact
with gpg in this situation, and that's why you see the error message - which
is utterly benign: duplicity doesn't even NEED the remote manifest in
that situation (earlier on it's logged that "local and remote are in sync").
i'll raise a bug with upstream to improve the logging for this situation.
"There are only two industries that refer to their customers
as 'users'." -- Edward Tufte
severity 880111 minor
tags 880111 - moreinfo
thanks
On Wed, 01 Nov 2017 20:19:31 +0100, Francesco Poli writes:
>> 2. could you run another backup invocation with -v9 and attach the output?
>Attached as duplicity.out
thanks for your diagnostic data.
>I cannot spot the error there, though... :-|
yes, there is no problem in that run.
in the meantime i've started up a blank unstable chroot, and i can
reproduce the issue on incremental backups.
exec summary: please ignore that error message.
i've checked the source, and this is actually working as designed:
upstream changed the handling of remote manifests in 0.7.14
to more-or-less blindly attempt to access an encrypted remote manifest
and if unsuccessful, log that as a nonfatal 'error'.
http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/revision/1252/duplicity/collections.py
as far as i can tell duplicity doesn't even attempt to fully interact
with gpg in this situation, and that's why you see the error message - which
is utterly benign: duplicity doesn't even NEED the remote manifest in
that situation (earlier on it's logged that "local and remote are in sync").
i'll raise a bug with upstream to improve the logging for this situation.
"There are only two industries that refer to their customers
as 'users'." -- Edward Tufte
Francesco Poli
Nov 3, 2017, 2:00:02 PM11/3/17
to
On Fri, 03 Nov 2017 18:00:28 +1000 Alexander Zangerl wrote:
[...]
the stdout with
$ duplicity -v9 --archive-dir foo_archive --encrypt-key
XXXXXXXXXXXXXXXX \
--full-if-older-than 30D foo_dir/ file://foo_backup \
| tee duplicity.out
I didn't think about stderr, unfortunately.
If there was anything sent there, I believe it ended up mixed with
stdout, but not to file duplicity.out ...
>
> in the meantime i've started up a blank unstable chroot, and i can
> reproduce the issue on incremental backups.
Perfect, so the issue is reproducible on one of your setups.
Thanks a lot for taking the time to test it!
>
> exec summary: please ignore that error message.
>
> i've checked the source, and this is actually working as designed:
>
> upstream changed the handling of remote manifests in 0.7.14
> to more-or-less blindly attempt to access an encrypted remote manifest
> and if unsuccessful, log that as a nonfatal 'error'.
>
> http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/revision/1252/duplicity/collections.py
>
> as far as i can tell duplicity doesn't even attempt to fully interact
> with gpg in this situation, and that's why you see the error message - which
> is utterly benign: duplicity doesn't even NEED the remote manifest in
> that situation (earlier on it's logged that "local and remote are in sync").
Awkward...
>
> i'll raise a bug with upstream to improve the logging for this situation.
Thank you so much!
Looking forward to seeing this whole issue solved/clarified for the
best.
Now I have to figure out why "gpg --sign bar.txt" does not work for me
outside X... :-/
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
[...]
> On Wed, 01 Nov 2017 20:19:31 +0100, Francesco Poli writes:
> >> 2. could you run another backup invocation with -v9 and attach the output?
> ...
> >Attached as duplicity.out
>
> thanks for your diagnostic data.
>
> >I cannot spot the error there, though... :-|
>
> yes, there is no problem in that run.
Or maybe because the error was sent to stderr, but I only redirected
> >> 2. could you run another backup invocation with -v9 and attach the output?
> ...
> >Attached as duplicity.out
>
> thanks for your diagnostic data.
>
> >I cannot spot the error there, though... :-|
>
> yes, there is no problem in that run.
the stdout with
$ duplicity -v9 --archive-dir foo_archive --encrypt-key
XXXXXXXXXXXXXXXX \
--full-if-older-than 30D foo_dir/ file://foo_backup \
| tee duplicity.out
I didn't think about stderr, unfortunately.
If there was anything sent there, I believe it ended up mixed with
stdout, but not to file duplicity.out ...
>
> in the meantime i've started up a blank unstable chroot, and i can
> reproduce the issue on incremental backups.
Thanks a lot for taking the time to test it!
>
> exec summary: please ignore that error message.
>
> i've checked the source, and this is actually working as designed:
>
> upstream changed the handling of remote manifests in 0.7.14
> to more-or-less blindly attempt to access an encrypted remote manifest
> and if unsuccessful, log that as a nonfatal 'error'.
>
> http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/revision/1252/duplicity/collections.py
>
> as far as i can tell duplicity doesn't even attempt to fully interact
> with gpg in this situation, and that's why you see the error message - which
> is utterly benign: duplicity doesn't even NEED the remote manifest in
> that situation (earlier on it's logged that "local and remote are in sync").
>
> i'll raise a bug with upstream to improve the logging for this situation.
Looking forward to seeing this whole issue solved/clarified for the
best.
Now I have to figure out why "gpg --sign bar.txt" does not work for me
outside X... :-/
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Francesco Poli
Jan 28, 2018, 6:30:03 AM1/28/18
to
Control: found -1 duplicity/0.7.16-1
On Sun, 14 Jan 2018 05:09:07 +0000 Debian Bug Tracking System wrote:
> * New upstream release (closes: #802234, #880111)
I upgraded to duplicity/0.7.16-1, but I still get the error on
incremental backups:
===== Begin GnuPG log =====
gpg: encrypted with XXXX-bit XXX key, ID 0xXXXXXXXXXXXX, created XXXX-XX-XX
upstream release...
As far as I can say, it is still unfixed.
On Sun, 14 Jan 2018 05:09:07 +0000 Debian Bug Tracking System wrote:
> * New upstream release (closes: #802234, #880111)
I upgraded to duplicity/0.7.16-1, but I still get the error on
incremental backups:
===== Begin GnuPG log =====
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
gpg: public key decryption failed: No passphrase given
gpg: decryption failed: No secret key
===== End GnuPG log =====
Please clarify why this bug should be considered as fixed in the new
gpg: public key decryption failed: No passphrase given
gpg: decryption failed: No secret key
===== End GnuPG log =====
upstream release...
As far as I can say, it is still unfixed.
Alexander Zangerl
Jan 28, 2018, 5:40:04 PM1/28/18
to
On Sun, 28 Jan 2018 12:13:34 +0100, Francesco Poli writes:
>I upgraded to duplicity/0.7.16-1, but I still get the error on
>incremental backups:
upstream considers having this 'error message that is just a notice message'
>I upgraded to duplicity/0.7.16-1, but I still get the error on
>incremental backups:
to be _the_ fix. ie. benign and ignorable.
The only truly safe "embedded system" is the system that has
an axe embedded in it... -- Tanuki
Francesco Poli
Jan 29, 2018, 1:40:03 PM1/29/18
to
On Mon, 29 Jan 2018 08:24:56 +1000 Alexander Zangerl wrote:
> On Sun, 28 Jan 2018 12:13:34 +0100, Francesco Poli writes:
> >I upgraded to duplicity/0.7.16-1, but I still get the error on
> >incremental backups:
>
> upstream considers having this 'error message that is just a notice message'
> to be _the_ fix. ie. benign and ignorable.
Thanks for the explanation.
> On Sun, 28 Jan 2018 12:13:34 +0100, Francesco Poli writes:
> >I upgraded to duplicity/0.7.16-1, but I still get the error on
> >incremental backups:
>
> upstream considers having this 'error message that is just a notice message'
> to be _the_ fix. ie. benign and ignorable.
However, this sounds really weird to me: if an error or warning message
is totally harmless and should be ignored by the user, the most sensible
thing to do is to suppress the message, so that it is not shown to the
user at all.
I suspect that upstream will get a good number of bug reports
about this in the months and years to come, until the spurious
message is finally suppressed...
Maybe the message should be suppressed once and for all?
The sooner, the better.
Do you agree?
Could you please forward these considerations upstream?
Thanks for your time.
Bye!
0 new messages