Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1299304 > unrolled thread

Bug#1140518: duplicity: no longer performs (incremental?) backups with OpenPGP encryption

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1140518: duplicity: no longer performs (incremental?) backups with OpenPGP encryption "Francesco Poli (wintermute)" <invernomuto@paranoici.org> - 2026-06-21 23:10 +0200
    Bug#1140518: duplicity: no longer performs (incremental?) backups with OpenPGP encryption Francesco Poli <invernomuto@paranoici.org> - 2026-06-21 23:40 +0200
    Bug#1140518: duplicity: no longer performs (incremental?) backups with OpenPGP encryption Francesco Poli <invernomuto@paranoici.org> - 2026-06-23 10:10 +0200
      Bug#1140518: duplicity: no longer performs (incremental?) backups with OpenPGP encryption Alexander Zangerl <az@snafu.priv.at> - 2026-06-24 03:10 +0200

#1299304 — Bug#1140518: duplicity: no longer performs (incremental?) backups with OpenPGP encryption

Package: duplicity
Version: 3.0.8~dev5-1
Severity: important
X-Debbugs-Cc: invernomuto@paranoici.org

Hello there!

Since upgrading:

    [UPGRADE] duplicity:amd64 3.0.6.3-2 -> 3.0.8~dev5-1

I performed one full backup, but I could no longer perform incremental
backups with OpenPGP encryption:

    $ duplicity --encrypt-key 3E1C27E11F69BFFE --full-if-older-than 30D --include-filelist .duplicity.include . file://backup
    No valid action found. Will imply 'backup' because a path source was given and target is a url location.
    Reading globbing filelist .duplicity.include
    Local and Remote metadata are synchronized, no sync needed.
    Last full backup date: Fri Jun  5 18:45:22 2026
    Error processing remote file (duplicity-full.20260605T164522Z.manifest.gpg):
    Traceback (innermost last):
      File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 326, in get_remote_file
        remote_file_buffer = self.backend.get_data(remote_file)
      File "/usr/lib/python3/dist-packages/duplicity/backend.py", line 782, in get_data
        assert not fin.close(), "fin failed to close"
                   ~~~~~~~~~^^
      File "/usr/lib/python3/dist-packages/duplicity/dup_temp.py", line 248, in close
        assert not self.fileobj.close(), "self.fileobj failed to close"
                   ~~~~~~~~~~~~~~~~~~^^
      File "/usr/lib/python3/dist-packages/duplicity/gpg.py", line 324, in close
        self.gpg_failed()
        ~~~~~~~~~~~~~~~^^
      File "/usr/lib/python3/dist-packages/duplicity/gpg.py", line 291, in gpg_failed
        raise GPGError(msg)
     duplicity.gpg.GPGError: GPG Failed, see log below:
    ===== Begin GnuPG log =====
    gpg: encrypted with rsa4096 key, ID 0x12DFF4B093A5EC02, created 2010-12-08
    "Francesco Poli (wintermute) <invernomuto@paranoici.org>"
    gpg: using "0xCA0111479CD2EFDFFB8239253E1C27E11F69BFFE" as default secret key for signing
    gpg: public key decryption failed: No passphrase given
    gpg: decryption failed: No passphrase given
    ===== End GnuPG log =====


Please note that the previous version asked for the passphrase (which is
annoying, and I am not sure I understand why it needed to, as old versions
almost never had this need...). Now version 3.0.8~dev5-1 does not ask
for any passphrase, but complains that no passphrase was given and crashes!

Please fix this bug and/or forward this bug report upstream, as appropriate.

Thanks for your time and dedication!


-- System Information:
Debian Release: forky/sid
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 7.0.12+deb14.1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages duplicity depends on:
ii  gnupg              2.4.9-4
ii  libc6              2.42-16
ii  librsync2t64       2.3.4-1.1+b2
ii  python3            3.13.9-3+b1
ii  python3-fasteners  0.20-2
ii  python3-httplib2   0.31.2-2
ii  python3-lxml       6.1.0-1
ii  python3-paramiko   4.0.0-2
ii  python3-pexpect    4.9-4
ii  python3-psutil     7.1.0-1
ii  python3-requests   2.32.5+dfsg-1

Versions of packages duplicity recommends:
ii  python3-oauthlib  3.3.1-1
pn  python3-socks     <none>
ii  python3-urllib3   2.6.3-2
ii  rsync             3.4.4+ds1-1

Versions of packages duplicity suggests:
pn  b2sdk                <none>
pn  lftp                 <none>
pn  ncftp                <none>
pn  par2                 <none>
pn  python3-boto3        <none>
pn  python3-pip          <none>
pn  python3-swiftclient  <none>
pn  tahoe-lafs           <none>

-- no debconf information

[toc] | [next] | [standalone]

#1299306

[Multipart message — attachments visible in raw view] — view raw

On Sun, 21 Jun 2026 23:05:51 +0200 Francesco Poli (wintermute) wrote:

> Hello there!
> 
> Since upgrading:
> 
>     [UPGRADE] duplicity:amd64 3.0.6.3-2 -> 3.0.8~dev5-1
[...]

Downgrading to duplicity/3.0.6.3-2 fixes the bug, hence it definitely
looks like a regression in package 'duplicity' (probably an upstream
one).

I hope it can be fixed soon.


-- 
 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

[toc] | [prev] | [next] | [standalone]

#1299418

[Multipart message — attachments visible in raw view] — view raw

On Mon, 22 Jun 2026 11:27:20 +1000 Alexander Zangerl wrote:

> On Sun, 21 Jun 2026 23:05:51 +0200, "Francesco Poli (wintermute)"
> writes:
> >I performed one full backup, but I could no longer perform
> >incremental backups with OpenPGP encryption:
> >
> >    $ duplicity --encrypt-key 3E1C27E11F69BFFE --full-if-older-than
> > 30D --include-filelist .duplicity.include . file://backup  
> 
> since 3.0.6 you need to add --no-check-remote to your backup
> invocation if you want asymmetric encryption (as evident from your
> command line). that's documented in NEWS.Debian as a
> backwards-incompatible change that upstream made.

Hi Alexander,
thanks a lot for pointing this change out to me!

Shame on me, I didn't think to take a look at the NEWS.Debian file! I
should have checked there, before filing a bug report...

I can confirm that adding option '--no-check-remote' to the command
seems to make the incremental backups work again.

> 
> >Please note that the previous version asked for the passphrase
> >(which is annoying, and I am not sure I understand why it needed to,
> >as old versions almost never had this need...).  
> 
> it didn't ever actually need to, and it should never have tried to;
> 3.0.6 had some ugly hacks and special case code that attempted to
> guess whether it should ask or not.
> 
> in 3.0.8 all the broken code was removed, but upstream has not given
> up on the notion that decrypting all remote manifests on every backup
> is a good idea, which is why --no-check-remote is required and will
> remain.

Isn't this a bug anyway, even though of smaller severity?

I mean: without option '--no-check-remote', duplicity wants to decrypt
remote manifests, before backing anything up.
OK, let's assume that the user agrees.
In order to let this happen, the user has to provide the secret key,
thus needing to enter the passphrase to unlock the secret key.
But duplicity does not manage to make GnuPG ask for a passphrase to
unlock the secret key, even in cases where the secret key is available
locally...

Should this bug report be reopened with severity lowered to 'normal'
and title set to something like 'duplicity: no longer makes GnuPG ask
for a passphrase, when needed' ?
What do you think?

Please let me know, thanks for your time and patience!


-- 
 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

[toc] | [prev] | [next] | [standalone]

#1299512

[Multipart message — attachments visible in raw view] — view raw

On Tue, 23 Jun 2026 09:59:33 +0200, Francesco Poli writes:
>Isn't this a bug anyway, even though of smaller severity?

i don't think so, as the --no-check-remote option exists.

as far as i understand the relevant logic, the primary
assumption behind (force-)checking the remote manifests is 
that you either use symmetric encryption, or encrypt and sign and
with gpg-agent fully primed and ready or with passphrase(s) preset via
the environment.
my interpretation is that upstream considers this case, where the
backup machine can be (and is) trusted, but maybe not the repository, is
the more critical they want to cover.

the asymmetric encrypt-only scenario (which i personally also definitely
require) reverses the trust assumptions, and needs no remote manifest
checking.

i'd say there is no bug as long as both scenarios remain supported
(or until one is cleanly retired).

(see also the section 'A NOTE ON SYMMETRIC ENCRYPTION AND SIGNING' in
the duplicity manpage.)

regarding actual passphrase interaction i'm not certain what is and
isn't supported with what exact version of gpg2, with respect to
operation without gpg-agent. personally i don't use gpg2.


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
The terrorists have won. They have successfully convinced America to
attack itself. -- Steve Kirsch

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web