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. _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
