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
>
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, /code.launchpad .net/~hooloovoo /duplicity/ add-additional- verify- tests-for- corrupted- archives /bugs.launchpad .net/bugs/ 601660 /bugs.launchpad .net/duplicity/ +bug/601660/ +subscriptions
>
> 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:/
> (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:/
>
> 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:/
>