Suggestion: Allow validate_encryption_settings() to be avoided

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestion: Allow validate_encryption_settings() to be avoided

duplicity-talk mailing list
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 mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion: Allow validate_encryption_settings() to be avoided

duplicity-talk mailing list
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

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk