Resuming a backup with a different password should throw an error

[Michael Terry]

To reproduce:
1) Backup with an encryption password, say "test"
2) Interrupt the backup
3) Resume the backup with a different encryption password

I would expect a typical GPG decryption error, but duplicity just continues on its merry way. And now you have a backup half encrypted with one password, half encrypted with another.

Presumably, this is because when resuming, duplicity does not need to decrypt anything. The local cached manifest is not encrypted and it doesn't need to refetch any volumes. Perhaps it should always try to download and decrypt volume 1 to test the password?

I'm attaching a test script to reproduce.

(Ubuntu 11.10, duplicity 0.6.15)

[Michael Terry (mterry)]

Here's a slightly better version of the script.

If you get two "Yes!" outputs at the bottom, the bug exists.
If you get one "Yes!" and one "No vol3 exists" outputs, the bug is fixed (duplicity refused to restart the backup).

[Michael Terry (mterry)]

And here's a script that tests the ability to prevent switching from encrypted to non-encrypted.

[Tim Ruffing (8-public)]

I don't think this is fixed properly.

Let me sum up the change:
In the new function validate_encryption_settings, the first volume is decrypted to see if the provided passphrase matches the one from the aborted backup run.

This makes sense for symmetric encryption. However for public key encryption, we can just check if the recipients are the same. There is no need to decrypt anything in the whole process (or do we need somewhere else?), so we do not need any private decryption keys.
duplicity 0.6.21 requests those keys:

 RESTART: Volumes 7 to 9 failed to upload before termination.
         Restarting backup at volume 7.
[...]
===== Begin GnuPG log =====
gpg: encrypted with 2048-bit RSA key, ID BA6C3E32, created 2013-08-15
"KEY TO ENCRYPT MY BACKUPS (I will never use this key to encrypt anything else than my personal backups. I will never use this key to sign anything.)"
gpg: public key decryption failed: bad passphrase
gpg: decryption failed: secret key not available
===== End GnuPG log =====

(Here I did not provide a passphrase. But the point is that duplicity wants to have the private key.)

The only exception: Hidden recipients. There is no obvious solution:
 - Detecting added hidden recipients could be done by trying to decrypt, like for the symmetric case. But this is again not great for those who want to store their private keys somewhere else or for unattended backups.
 - For removed (and added) hidden recipients, one could store the recipients in the local cache as long as the backup is not finished. Since they should be hidden, that does not sound like a good idea either.
 - Or just live with the fact that parts of the backup can be decrypted with different keys in this special case...