Re: [Duplicity-talk] remove-all-inc-of-but-n-full <num> and decryption

[Dirk-Willem van Gulik]

On 08 Nov 2015, at 17:21, Kenneth Loafman <address@hidden> wrote:

Could you explain "As I sort of need to give duplicity credentials that on sftp level already allow that environment to ‘corrupt’ my backups."?  I seem to be dense today.

So a nice property of duplicity is that it can (largely) operate with just a public key for backups. 

That means you can keep the corresponding private key ‘offline’ and only break into it during a restore. This significantly reduces the footprint & risks around backups. And makes a lot of threatmodel around remote servers & cloud/hosted situations simpler.

Now obviously duplicity will need a fair bit of credentials on the servers it is backing up - at the very least enough to read (though not modify) the files & directories it is backing up. And it will need some credentials sufficient to ’sftp’ (or similar) to the storage systems that allow the creation & writing of files.

In actual practice that means that in a lot of situations duplicity can also ‘corrupt’ its own backup. Because of a adversary has gotten sufficient control over it or its environment -or- because of a simple bug in the code.

Hence allowing duplicity to delete (old) backups with just the public key is not that much of a weakening of the security situation; and will not change the risk- and threatmodel much, if at all. 

Does that help ?

Dw