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

[edgar . soldin]

On 18.04.2018 06:56, Arnold Same via Duplicity-talk wrote:
> 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.
> 

hey Arnold,

whilst this would be possible, the safer (in terms of your backed up data) 
solution would be to use the double key approach as described in this thread
  https://lists.nongnu.org/archive/html/duplicity-talk/2014-06/msg00046.html

tl;dr
there is a small, but existing possibility to corrupt your backup chain if 
duplicity is not able to decrypt data from the backend. that's only possible w/ 
a private key for async encrypted backups. solution: encrypt against two public 
keys, your own and a local key pair, that is specific for this machine.

..ede/duply.net