duplicity allows a new, different passphrase if an archive cache exists
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Duplicity |
Fix Released
|
Undecided
|
Unassigned | ||
Déjà Dup |
Fix Released
|
Critical
|
Unassigned | ||
deja-dup (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Trusty |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
High
|
Unassigned | ||
duplicity (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Trusty |
Won't Fix
|
Undecided
|
Unassigned | ||
Xenial |
Won't Fix
|
Undecided
|
Unassigned | ||
Yakkety |
Won't Fix
|
Undecided
|
Unassigned | ||
Bionic |
Won't Fix
|
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-
- $ deja-dup --backup # complete first encrypted full backup
- $ rename 's/\.2016/\.2000/' /path/to/
- $ rename 's/\.2016/\.2000/' ~/.cache/
- $ 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.
Changed in deja-dup: | |
status: | Fix Committed → Fix Released |
description: | updated |
tags: |
added: verification-needed-xenial removed: verification-needed |
description: | updated |
no longer affects: | deja-dup (Ubuntu Precise) |
tags: | added: verification-done-xenial |
tags: |
added: verification-done-yakkety removed: verification-needed |
Changed in duplicity: | |
status: | New → Confirmed |
Changed in duplicity (Ubuntu): | |
importance: | Undecided → High |
Changed in duplicity (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in duplicity: | |
status: | Confirmed → Fix Released |
Changed in deja-dup (Ubuntu Bionic): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in duplicity (Ubuntu Trusty): | |
status: | Confirmed → Won't Fix |
Changed in duplicity (Ubuntu Xenial): | |
status: | Confirmed → Won't Fix |
Changed in duplicity (Ubuntu Bionic): | |
status: | New → Won't Fix |
Changed in deja-dup (Ubuntu Bionic): | |
status: | Triaged → Fix Committed |
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!)