[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Duplicity-talk] Suggestion: Allow validate_encryption_settings() to be
From: |
Arnold Same |
Subject: |
[Duplicity-talk] Suggestion: Allow validate_encryption_settings() to be avoided |
Date: |
Wed, 18 Apr 2018 00:56:43 -0400 |
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.
- [Duplicity-talk] Suggestion: Allow validate_encryption_settings() to be avoided,
Arnold Same <=