Your message dated Mon, 22 Jun 2026 11:27:20 +1000
with message-id <[email protected]>
and subject line Re: Bug#1140518: duplicity: no longer performs (incremental?) 
backups with OpenPGP encryption
has caused the Debian Bug report #1140518,
regarding duplicity: no longer performs (incremental?) backups with OpenPGP 
encryption
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
1140518: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140518
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: duplicity
Version: 3.0.8~dev5-1
Severity: important
X-Debbugs-Cc: [email protected]

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) <[email protected]>"
    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

--- End Message ---
--- Begin Message ---
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.

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


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
I am Dyslexia of Borg. Prepare to have your arse laminated.

Attachment: signature.asc
Description: Digital Signature


--- End Message ---

Reply via email to