After duplicity a password is prompted unexpectedly

[jolexin]

For years I have backed up selected files to an external HD drive, which contains an encrypted ext4 partition. I am doing this with the following duplicity command (inside a script):

duplicity incremental --no-encryption --exclude-other-filesystems /home/xxxx file:///run/media/jaro/ext4-Datsi-extrn/yyyy

xxxx and yyyy are placeholders for detailed paths, which are beyond interest here.
The messages that I always see in the terminal window are:

Lokale und entfernte Metadaten sind bereits synchron, kein Abgleich benötigt.
(local and remote data are synchronous, no reconciliation needed)
Last full backup date: Thu May 22 10:24:39 2025

Today, 2025-12-14, I saw additional messages:

No encryption keys configured.
No environment variables are set, asking user.
GnuPG passphrase for decryption:

I had no idea, which encryption keys and environment variables were suddenly missing; therefore I also had no idea, which passphrase I should enter. What I have done:

1. I typed ENTER, that yielded another message:

Bei symmetrischer Verschlüsselung darf keine leere Passphrase benutzt werden! Bitte nochmal versuchen.
(empty passphrase ist forbidden for symmetric encryption; please repeat)
GnuPG passphrase for decryption:

2. After several repetitions I entered some key combination (twice).

Now my script ended as usual. I looked into the target folder and there I saw new files

duplicity-inc.20251130T215534Z.to.20251209T142223Z.manifest,
duplicity-new-signatures.20251130T215534Z.to.20251209T142223Z.sigtar.gz
duplicity-inc.20251130T215534Z.to.20251209T142223Z.vol1.difftar.gz

That indicates that the backup was done as usual, however, afterwards something was symmetrically encrypted, but what?

Can someone offer an explanation? Did duplicity change its behaviour after recent SW update?

[megavolt]

It seems to me that there is a logical error whereby Duplicity assumes that you are using symmetric encryption (AES) if you are not using asymmetric encryption (GPG). The --no-encryption option has probably not been tested as it is rarely used. If you do not want encryption or signing, simply set PASSPHRASE to an empty string. However, signing is still a good idea, even if it uses SHA1 checksums.

[jolexin]

I chose duplicity with no-encryption, because the target of the backup is an encrypted partition. I have been using the above command option for several years!

If I hit ENTER, which means empty passphrase, the password prompt re-appears. So I must set a password.

But why did that password prompt never appear before? Why does it appear now? And what is the object that is encrypted?

[megavolt]

@jolexin

I chose duplicity with no-encryption, because the target of the backup is an encrypted partition. I have been using the above command option for several years!

Then you probably do, but behavior can always change. Maybe it’s a bug. Are you sure that something is actually being signed or encrypted when you enter a password or no password and --no-encryption is set?

@jolexin

If I hit ENTER, which means empty passphrase, the password prompt re-appears. So I must set a password.

That’s why I’m writing:

@megavolt

If you do not want encryption or signing, simply set PASSPHRASE to an empty string.

→ export PASSPHRASE=""

@jolexin

But why did that password prompt never appear before? Why does it appear now? And what is the object that is encrypted?

These are questions that a duplicity developer can answer, or you can simply read the source code: duplicity/dup_main.py · dev · duplicity / duplicity · GitLab But you probably won’t do that. You can also use an AI of your choice to help you understand the logic bug.