duplicity allows a new, different passphrase if an archive cache exists

[Allison Karlitskaya]

when doing a backup for the first time, dejadup verifies your passphrase by having you enter it twice.

on future incremental backups it doesn't need to do this because entering the wrong password will result in the backup failing.

with the periodic 'full' backups that happen from time to time, however, any password will be accepted.

this can lead to a situation where you accidentally type the wrong password once and are left in a situation where you don't know what you typed and have no way to get your files (or do another incremental backup on top of it).

i think this is what happened to me recently.

clearly, the fix is to explicitly verify the passphrase is correct when doing a new full backup. this may be a duplicity bug.

=== Ubuntu deja-dup SRU information ===

[impact]
Users may unwittingly re-set their backup password and not be able to restore their data.

[test case]
- $ deja-dup-preferences # set up a dummy backup
- $ deja-dup --backup # complete first encrypted full backup
- $ rename 's/\.2016/\.2000/' /path/to/test/backup/*
- $ rename 's/\.2016/\.2000/' ~/.cache/deja-dup/*/*
- $ deja-dup --backup # second backup, enter the wrong password
- $ deja-dup --restore # try to restore with original password

[regression potential]
Should be limited? The fix is to delete the duplicity cache files, which ought to be safe to delete.

It's possible if a full backup is being resumed, we might delete the current progress. That is a better bug to have than this bug, though. A more complicated patch would need to be investigated to prevent that.

[davee (davee-sungate)]

Yes, the submitter has correctly assessed the nature of the problem: this stung me too. On the first incremental after a new full, Deja Dup would not accept my 'usual' passphrase: thus, my conclusion is that the new full was previously made with the 'wrong' passphrase.

I've never been too careful about typing the passphrase, because my understanding was that it checks the passphrase against previous backups and rejects it if there's a conflict.

If this check doesn't happen for new full backups, then either (a) it *should* or (b) it should give the PASSPHRASE and CONFIRM PASSPHRASE twin prompts.

(I've had to simply delete the new full backup I made, because I can't work out its passphrase, despite trying a few obvious typos from my 'usual' passphrase!)

[Vej (vej)]

This seems to be a potentially big problem. I will do more testing and set the status afterwards.

[Naël (nathanael-naeri)]

This is indeed critical and needs to be brought directly to the attention of the developer (Michael Terry) as soon as Vej can confirm.

[Vej (vej)]

Hello everyone.

I can confirm this and will inform the mailinglist.

Best

Vej

[Michael Terry (mterry)]

Yikes. OK I'll look at this.

[Michael Terry (mterry)]

It does seem like duplicity isn't doing a very good job of protecting the user here. It doesn't explicitly validate the latest full-backup password against older backup chains.

It *will* validate the password if it has lost its local already-decrypted copy of the metadata for old backups and has to re-download and re-decrypt them. So as a workaround, I've added some logic in deja-dup to blow away the cache before doing a fresh full backup.

But probably duplicity should be smarter in this case.

[Launchpad Janitor (janitor)]

This bug was fixed in the package deja-dup - 34.3-0ubuntu1

---------------
deja-dup (34.3-0ubuntu1) zesty; urgency=medium

  * New bug-fix upstream release:
    - Fixes a bug that allowed an incorrect password when making a
      new full backup (LP: #918489)

 -- Michael Terry <email address hidden> Sun, 27 Nov 2016 17:21:31 -0500

[Brian Murray (brian-murray)]

Hello Allison, or anyone else affected,

Accepted deja-dup into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/deja-dup/34.2-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

This seems important enough to fix in Yakkety. Could you do that Michael?

[Michael Terry (mterry)]

I uploaded an update to trusty and yakkety.

[Brian Murray (brian-murray)]

Hello Allison, or anyone else affected,

Accepted deja-dup into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/deja-dup/34.2-0ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Allison, or anyone else affected,

Accepted deja-dup into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/deja-dup/30.0-0ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Michael Terry (mterry)]

I tested on trusty and that one worked well. Additionally, I tested the thought I had that my deja-dup patch might cause a regression when resuming a full backup. I noted this concern in the bug description after I wrote the patch.

But thankfully, it does not. Resuming full backups work as intended (both initial backup and a later checkpoint backup). And they validate passwords correctly. So, phew.

Will try to test xenial and yakkety today.

[Launchpad Janitor (janitor)]

This bug was fixed in the package deja-dup - 30.0-0ubuntu4.1

---------------
deja-dup (30.0-0ubuntu4.1) trusty; urgency=medium

  * debian/patches/clear-cache-before-full-backup.patch:
     - Fixes a bug that allowed an incorrect password when making a
      new full backup (LP: #918489)

 -- Michael Terry <email address hidden> Thu, 08 Dec 2016 10:01:04 -0500

[Chris J Arges (arges)]

The verification of the Stable Release Update for deja-dup has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package deja-dup - 34.2-0ubuntu1.1

---------------
deja-dup (34.2-0ubuntu1.1) xenial; urgency=medium

  * debian/patches/clear-cache-before-full-backup.patch:
    - Fixes a bug that allowed an incorrect password when making a
      new full backup (LP: #918489)

 -- Michael Terry <email address hidden> Fri, 02 Dec 2016 16:07:55 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package deja-dup - 34.2-0ubuntu3.1

---------------
deja-dup (34.2-0ubuntu3.1) yakkety; urgency=medium

  * debian/patches/clear-cache-before-full-backup.patch:
    - Fixes a bug that allowed an incorrect password when making a
      new full backup (LP: #918489)

 -- Michael Terry <email address hidden> Thu, 08 Dec 2016 09:26:13 -0500

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Terry (mterry)]

I think this has gotten even worse in duplicity. I believe this used to only affect full backups. But now it seems to affect incremental backups too.

I've attached a simple reproduction script. It basically just does:

PASSPHRASE=one duplicity full /tmp/testdir file://$DIR
PASSPHRASE=two duplicity /tmp/testdir file://$DIR

Although the second duplicity run complains about a bad password, it will still continue and make an incremental backup with a different passphrase than the full volumes.

Tested with duplicity 0.7.18.2.

I've worked around this behavior in deja-dup 39.1.

[Yajo (yajo)]

Although comment 22 is IMHO a duplicity bug, the fact that you can do a full backup with a new passphrase is, for me, a feature. If somebody had access to your passphrase, the safe thing to do is to rotate it, do a full backup, and stick with the new one from there onwards.

There's a problem restoring, but that's another issue.

[Jens (jens-launchpad-net)]

IMHO: A backup software that has a "problem when restoring" is completely worthless, not "another issue".

If you are doing an encrypted backup and somebody gets access to your passphrase, the safe thing to do is create a completely new backup with a new passphrase, and wipe (and destroy) all existing backup copies, caches and everything else ASAP since it's basically an unencrypted backup.

Just IMHO.

[Michael Terry (mterry)]

It escaped my attention at the time, but Ubuntu 18.04 released with both a version of duplicity that shows the new incremental-backups-also-have-this-issue behavior (see my comment 22) and a release of deja-dup that wasn't yet fixed to avoid it.

Which means that deja-dup in Ubuntu 18.04 is still affected by this bug (for incremental backups).

These two commits landed in deja-dup 39.1 and should work around it, if someone wanted to patch deja-dup in 18.04 (I've opened a target for bionic for this bug):
https://gitlab.gnome.org/World/deja-dup/-/commit/4f325940dae7fc259b4be70fccec40c94617f4d4
https://gitlab.gnome.org/World/deja-dup/-/commit/135f4c83774b6dafe194236f99f1405f45032498

For users, you can also install the snap version of deja-dup to avoid this as well.

[Sebastien Bacher (seb128)]

Upstream closed the duplicity task without details so let's assume it's fixed in the current version and Ubuntu serie

[Robie Basak (racb)]

From a quick glance at the code, Xenial doesn't look fixed to me. Bionic has the issue and so the SRU for Bionic is correct. Focal has the issue fixed.

Since Xenial is past the end of standard support I expect it won't be fixed for this issue anyway, but I'm just noting that the bug status may be wrong.

[Robie Basak (racb)]

Hello desrt, or anyone else affected,

Accepted deja-dup into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/deja-dup/37.1-2fakesync1ubuntu0.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Michael Terry (mterry)]

I tested this and it worked!

- Made an initial backup, not saving password.
- Backed up again, changing the password.

With the old version, I got an error at "verify the backup" step. But the backup files did end up being written with the wrong password.

With the new version, it did not accept the wrong password and re-prompted me for the password (correct behavior).

Thank you for uploading the fix!

[Launchpad Janitor (janitor)]

This bug was fixed in the package deja-dup - 37.1-2fakesync1ubuntu0.2

---------------
deja-dup (37.1-2fakesync1ubuntu0.2) bionic; urgency=medium

  * debian/patches/invalid_password_handling.patch:
    - handle correctly when an invalid password is entered
      (lp: #918489)

 -- Sebastien Bacher <email address hidden> Thu, 25 Nov 2021 17:53:50 +0100