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

[Kenneth Loafman]

Interesting analysis and discussion.

I don't recall when we removed the check for the same passphrase, but it was removed a few revisions ago because it increased bandwidth use.  I'm thinking we should add it back in again, but instead of testing it by decrypting a file, we should just hash the original and store it in the cache for later comparison.  We could use a strong hash like sha512 and strong permissions on the file.

Downside?

...Ken

On Tue, Aug 24, 2021 at 5:26 AM edgar.soldin--- via Duplicity-talk <duplicity-talk@nongnu.org> wrote:

On 24.08.2021 12:21, edgar.soldin@web.de wrote:
>> So, as Edgar suggested, my duplicity backup does have two different passphrases, a first for the original full backup, and a second for everything else.  Is there anyway to get duplicity to use the two passphrases correctly, or is my only option to manually decrypt the the 4 files (1 manifest, 2 difftars, and 1 sigtar) with the first passphrase and re-encrypt them with the second passphrase and then replace the 4 original files with the re-encrypted ones?
> the manual re-encryption should do the trick. duplicity is not prepared for a user error like that unfortunately. for the future i strongly suggest to set the PASSPHRASE env var or use gpg-agent or even better key based auth, where that error is simply not possible.
>

you may also consider using the duply commandline frontend, to make handling duplicity parameters a little simpler.

..ede/duply.net

_______________________________________________
Duplicity-talk mailing list
Duplicity-talk@nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk