[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] decryption failure in duplicity replicate

From: edgar . soldin
Subject: Re: [Duplicity-talk] decryption failure in duplicity replicate
Date: Wed, 25 Aug 2021 12:33:24 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 25.08.2021 10:26, zga9uhnq4g--- via Duplicity-talk wrote:
> Okay, I tried re-encrypting the 2020-12-12 files and copying them back to 
> OneDrive, but when I ran "duplicity verify --time 2020-12-12 ..." I got
>     Local and Remote metadata are synchronized, no sync needed.
>     Last full backup date: Wed Aug 11 02:01:44 2021
>     Invalid data - SHA1 hash mismatch for file:
>      duplicity-full.20201212T204209Z.vol1.difftar.gpg
>      Calculated hash: bcac07d8b88aeff2b928090c35db072fe1444f47
>      Manifest hash: 0529e8d2384b24dec4d771f50dacca7d585188f8
> So must have done something wrong.  The command I used to reencrypt was
>     gpg2 --symmetric --cipher-algo AES256 $file
> Do I need to give more or different option to gpg?

no, the re-encryption seems to have enabled duplicity to decrypt the files now.

the error comes from duplicity now as it correctly sees that the volumes were 
modified after their first creation. it's possible that adding 
'--ignore-errors' will not fail on the error but that should only be a last 
resort, as it'll silently ignore other errors too, that might theoretically 
there. nope, just tested, fails still.

just did some local tests and it looks like the hash is saved in the manifest 
file under
Volume 1:
    StartingPath   ...
    EndingPath     ...
    Hash SHA1 df901ba65335d73e6e9724c4fc9ed79adda4dfac
it should contain 0529e8d2384b24dec4d771f50dacca7d585188f8 now, replace it with 
0529e8d2384b24dec4d771f50dacca7d585188f8, encrypt the new manifest and that 
should get rid of the failed checksum in duplicity. you may need to do this for 
all volumes obviously. 'sha1sum' can help you.

if that does not work instantly it might be because duplicity caches manifests 
from remote. delete the archive dir cache for the repo to force duplicity to 
become aware of the change. easiest is to provide a  '--name foobar', then you 
will find the folder under .cache/duplicity/foobar . delete it after you did 
changes to your test repo and run duplicity only after and it will be recreated.

for your tests you may just place the files in a folder locally and run 
"duplicity verify file:///absolute/local/folder". you can leave out time if you 
just place the first full (and later incrementals) there as duplicity will test 
the one chain it should find.

to make it maybe even more easier/complicated you may try working with the 
unencrypted files by putting them in a folder and run duplicity like "duplicity 
collection-status --no-encryption --no-compression 
file:///absolute/local/folder" . that might probably fail though due to the 
checksums from above not being modified too.

good luck ..ede/duply.net

reply via email to

[Prev in Thread] Current Thread [Next in Thread]