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

Bug #918489 reported by desrt on 2012-01-19
124
This bug affects 19 people
Affects Status Importance Assigned to Milestone
Duplicity
Undecided
Unassigned
Déjà Dup
Critical
Unassigned
deja-dup (Ubuntu)
Undecided
Unassigned
Trusty
Undecided
Unassigned
Xenial
Undecided
Unassigned
Yakkety
Undecided
Unassigned
duplicity (Ubuntu)
High
Unassigned
Trusty
Undecided
Unassigned
Xenial
Undecided
Unassigned
Yakkety
Undecided
Unassigned

Bug Description

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) wrote :

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) wrote :

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

Changed in deja-dup:
importance: Undecided → Critical
Naël (nathanael-naeri) wrote :

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) wrote :

Hello everyone.

I can confirm this and will inform the mailinglist.

Best

Vej

Changed in deja-dup:
status: New → Triaged
Michael Terry (mterry) wrote :

Yikes. OK I'll look at this.

Michael Terry (mterry) wrote :

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.

Changed in deja-dup:
status: Triaged → Fix Committed
summary: - dejadup allows bad passphrase on full backup
+ duplicity allows bad passphrase on full backup if archive cache exists
Michael Terry (mterry) on 2016-11-27
Changed in deja-dup:
status: Fix Committed → Fix Released

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

Changed in deja-dup (Ubuntu):
status: New → Fix Released
Michael Terry (mterry) on 2016-12-02
description: updated

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!

Changed in deja-dup (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed

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

Changed in deja-dup (Ubuntu Yakkety):
status: New → Triaged
Michael Terry (mterry) on 2016-12-08
tags: added: verification-needed-xenial
removed: verification-needed
description: updated
no longer affects: deja-dup (Ubuntu Precise)
Michael Terry (mterry) wrote :

I uploaded an update to trusty and yakkety.

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!

Changed in deja-dup (Ubuntu Yakkety):
status: Triaged → Fix Committed
tags: added: verification-needed
Changed in deja-dup (Ubuntu Trusty):
status: New → Fix Committed
Brian Murray (brian-murray) wrote :

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!

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.

tags: added: verification-done-trusty
removed: verification-needed-xenial
Michael Terry (mterry) on 2016-12-09
tags: added: verification-done-xenial
Michael Terry (mterry) on 2016-12-09
tags: added: verification-done-yakkety
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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

Changed in deja-dup (Ubuntu Trusty):
status: Fix Committed → Fix Released

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.

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

Changed in deja-dup (Ubuntu Xenial):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in deja-dup (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in duplicity (Ubuntu Trusty):
status: New → Confirmed
Changed in duplicity (Ubuntu Xenial):
status: New → Confirmed
Changed in duplicity (Ubuntu Yakkety):
status: New → Confirmed
Changed in duplicity (Ubuntu):
status: New → Confirmed
Michael Terry (mterry) wrote :

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.

summary: - duplicity allows bad passphrase on full backup if archive cache exists
+ duplicity allows a new, different passphrase if an archive cache exists
Vej (vej) on 2019-04-07
Changed in duplicity:
status: New → Confirmed
Changed in duplicity (Ubuntu):
importance: Undecided → High
Vej (vej) on 2019-04-07
Changed in duplicity (Ubuntu):
status: Confirmed → Triaged
Yajo (yajo) wrote :

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) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments