duplicity-team team mailing list archive

[edso <edgar.soldin@xxxxxx>]

hey Martin,

are you aware of the "no private key issue/double key approach" as eg. described here
  https://lists.gnu.org/archive/html/duplicity-talk/2017-10/msg00015.html
?

On 23.04.2018 15:50, Martin Nowak wrote:
> Seems like it tries to catch corruptions see https://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/view/1301/bin/duplicity#L1333 and https://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/view/1301/duplicity/collections.py#L218.

ok, isee the manifests are compared, which sounds reasonable.

> Given that this is not possible with an encrypted backup (without the key and/or password) 

it is ;) when a private key and passphrase (might be empty) for one of the used public keys is available.
as i don't see a way to easily detect a private key available (duply has some shell gpg trickery for this though) i don't see a problem logging the gpg error as a warning and simply continue.

>
and that the check hasn't been done despite the "non-fatal" error message, it seems fine to me to just skip it.
> 

i'd rather log a warning that the comparison was skipped because of the decryption impossibility, so the user may be informed that a /surplus/ security measure was not applied.

finally: the current mode of allowing incrementals w/o validating the backend is error prone[1] and should be replaced in a future version of duplicity. but as it stands, nobody took care of it until today.

food for thought ..ede/duply.net

[1] https://bugs.launchpad.net/duplicity/+bug/687295

-- 
https://code.launchpad.net/~dawgfoto/duplicity/fixup1252/+merge/343816
Your team duplicity-team is requested to review the proposed merge of lp:~dawgfoto/duplicity/fixup1252 into lp:duplicity.