verify command does not penetrate cache/archive

Bug #601660 reported by Peter Schuller
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Duplicity
Fix Released
Undecided
Unassigned

Bug Description

Running "duplicity verify URL dest" should never use any data from the persistent cache/archive that would otherwise be obtained from the remote backup, as the purpose of running the command is to verify the correctness of the backup data independently of any locally stored information.

The test I ran to conclude that this was a problem was:

(1) duplicity src file://./dest
(2) Modify a manifest file in ~/.cache to contain the wrong hash.
(3) still succeeds: duplicity verify file://./dest src

Indeed, testing actual server-side corruption confirms it:

(1) duplicity src file://./dest
(2) Modify a random byte in a manifest file in dest
(3) still succeeds: duplicity verify file://./dest src

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

Peter,

Is there any chance you could please re-test this on the trunk, as I suspect it has been fixed?

The tests that I added in:
https://code.launchpad.net/~hooloovoo/duplicity/add-additional-verify-tests-for-corrupted-archives
(now merged) were designed to corrupt the destination archives, rather than the cache, and these tests are passing as expected.

In your description above, did you mean:
"Modify a manifest file in dest to contain the wrong hash." rather than
"Modify a manifest file in ~/.cache to contain the wrong hash"?

As I understand it, you are saying that the cache should be ignored in any verify, so changing the cache shouldn't stop the verify succeeding.

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote : Re: [Bug 601660] Re: verify command does not penetrate cache/archive

The cache should be verified as well during the verify step. It would not
be good to skip it or delete it.

Also, as part of verification without the compare-data option, there should
be a step that makes sure that all of the difftar volumes exist in the
remote archive that are supposed to be there, a simple list and step
through process that would validate without download. A future manifest
should probably have the difftar file size as well.

On Tue, Dec 30, 2014 at 9:10 AM, Aaron Whitehouse <<email address hidden>
> wrote:

> Peter,
>
> Is there any chance you could please re-test this on the trunk, as I
> suspect it has been fixed?
>
> The tests that I added in:
>
> https://code.launchpad.net/~hooloovoo/duplicity/add-additional-verify-tests-for-corrupted-archives
> (now merged) were designed to corrupt the destination archives, rather
> than the cache, and these tests are passing as expected.
>
> In your description above, did you mean:
> "Modify a manifest file in dest to contain the wrong hash." rather than
> "Modify a manifest file in ~/.cache to contain the wrong hash"?
>
> As I understand it, you are saying that the cache should be ignored in
> any verify, so changing the cache shouldn't stop the verify succeeding.
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/601660
>
> Title:
> verify command does not penetrate cache/archive
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> Running "duplicity verify URL dest" should never use any data from the
> persistent cache/archive that would otherwise be obtained from the
> remote backup, as the purpose of running the command is to verify the
> correctness of the backup data independently of any locally stored
> information.
>
> The test I ran to conclude that this was a problem was:
>
> (1) duplicity src file://./dest
> (2) Modify a manifest file in ~/.cache to contain the wrong hash.
> (3) still succeeds: duplicity verify file://./dest src
>
> Indeed, testing actual server-side corruption confirms it:
>
> (1) duplicity src file://./dest
> (2) Modify a random byte in a manifest file in dest
> (3) still succeeds: duplicity verify file://./dest src
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/601660/+subscriptions
>

Changed in duplicity:
status: New → Fix Released
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.