[Duplicity-talk] Suggestion: Allow validate_encryption_settings() to be avoided

[Arnold Same]

Dear list,

Firstly, thank you for duplicity!

I have a suggestion for a new CLI flag, which should make resuming backups easier for users who keep their decryption key (or rather, private, encryption key) off the machine being backed-up (e.g. on a smart-card/YubiKey).

When resuming interrupted backups, I've encountered problems from the validate_encryption_settings function.

This function serves its purpose of  detecting changes in encryption schemes between a start and a restart, but at the cost of requiring decryption, which means that resuming backups without the decryption key will fail. It would be nice if users who know that they haven't changed their encryption settings could opt to disable this functionality.

I've hacked around this by commenting out the call to validate_encryption_settings in /usr/bin/duplicity. This produces the desired results. However, ideally its invocation could be controlled via a CLI flag, perhaps along the lines of:

    --no-validate-encryption-settings

          By default, when restarting a backup, duplicity will validate the that encryption settings have not changed in the interim by decrypting volume 1 on the destionation. However, this requires access to the decryption key, which may not be desirable. This switch disables that behavior.

         

Which could logic-gate the call to validate_encryption_settings in duplicity.py.

         

I attempted to produce a patch to offer, but I'm afraid I'm not familiar enough with the codebase, BZR or mailing-list collaboration to produce anything useful. However, I hope the maintainers might think it useful enough.