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.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to duplicity in Ubuntu.
https://bugs.launchpad.net/bugs/918489
Title:
duplicity allows a new, different passphrase if an archive cache
exists
Status in Déjà Dup:
Fix Released
Status in Duplicity:
Confirmed
Status in deja-dup package in Ubuntu:
Fix Released
Status in duplicity package in Ubuntu:
Triaged
Status in deja-dup source package in Trusty:
Fix Released
Status in duplicity source package in Trusty:
Confirmed
Status in deja-dup source package in Xenial:
Fix Released
Status in duplicity source package in Xenial:
Confirmed
Status in deja-dup source package in Yakkety:
Fix Released
Status in duplicity source package in Yakkety:
Confirmed
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/deja-dup/+bug/918489/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
