Incremental backups do not validate passphrase

Bug #1828761 reported by Tom Boshoven
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Duplicity
New
Undecided
Unassigned
duplicity (Ubuntu)
New
Low
Unassigned

Bug Description

This was reported in a comment on another bug, but I think this is serious enough to warrant its own one. It broke my incremental backups and I just happened to notice.
The report with repro steps is https://bugs.launchpad.net/duplicity/+bug/918489/comments/22

The expected behavior would be to fail on invalid passphrases on incremental backups (or otherwise make it very clear that this is the user's responsibility).
I seem to remember testing this in the past and verifying that an error is raised.
Right now, it leads to corruption and a beautiful stack trace followed by a hanging application when trying to verify or restore:

GPG error detail: Traceback (innermost last):
  File "/bin/duplicity", line 1560, in <module>
    with_tempdir(main)
  File "/bin/duplicity", line 1546, in with_tempdir
    fn()
  File "/bin/duplicity", line 1398, in main
    do_backup(action)
  File "/bin/duplicity", line 1479, in do_backup
    verify(col_stats)
  File "/bin/duplicity", line 875, in verify
    for backup_ropath, current_path in collated:
  File "/usr/lib/python2.7/site-packages/duplicity/diffdir.py", line 276, in collate2iters
    relem1 = riter1.next()
  File "/usr/lib/python2.7/site-packages/duplicity/patchdir.py", line 521, in integrate_patch_iters
    for patch_seq in collated:
  File "/usr/lib/python2.7/site-packages/duplicity/diffdir.py", line 286, in collate2iters
    relem2 = riter2.next()
  File "/usr/lib/python2.7/site-packages/duplicity/patchdir.py", line 121, in difftar2path_iter
    tarinfo_list = [tar_iter.next()]
  File "/usr/lib/python2.7/site-packages/duplicity/patchdir.py", line 344, in next
    self.set_tarfile()
  File "/usr/lib/python2.7/site-packages/duplicity/patchdir.py", line 332, in set_tarfile
    assert not self.current_fp.close()
  File "/usr/lib/python2.7/site-packages/duplicity/dup_temp.py", line 227, in close
    assert not self.fileobj.close()
  File "/usr/lib/python2.7/site-packages/duplicity/gpg.py", line 305, in close
    self.gpg_failed()
  File "/usr/lib/python2.7/site-packages/duplicity/gpg.py", line 272, in gpg_failed
    raise GPGError(msg)
 GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: AES encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
===== End GnuPG log =====

GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: AES encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
===== End GnuPG log =====

If left unnoticed, the only way to go about it is manual recovery.
I'm updating my backup scripts to do some basic validation of the passphrase to make sure that a simple typo will not break my backups in the future.

duplicity 0.7.18.2 on Arch Linux, Python 3.7.3.

Revision history for this message
Josh Elliott (spacemanjosh) wrote :

I believe I'm encountering the same bug. Or at least I'm getting the same stack trace when attempting to restore a backup. In my case I had a hard drive failure and had to reinstall Ubuntu. Now I'm attempting to restore my backup with duplicity and it's failing in exactly the way you describe.

You mention having to do a "manual" recovery. What are the steps to successfully do that? I've been unable to find a solution so far.

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :
Changed in duplicity (Ubuntu):
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.