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!

[...]

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.

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

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.

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.

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.

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!

On Tue, 23 Jun 2026 09:59:33 +0200, Francesco Poli writes:

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.