duplicity-team team mailing list archive

[edgar.soldin@xxxxxx]

On 14.04.2020 15:08, Andreas Schmidt wrote:
> Question #689862 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/689862
>
> Andreas Schmidt gave more information on the question:
> Dear ede,
>
> thank you for your quick reply. You are right, by hindsight a lot of my questions are
> focusing more on gnupg and its integration into duplicity, than on duplicity itself.

wrt. integration. simply explained duplicity creates backup files and then encrypts them via gnupg. or to say it in another way essentially there is no difference to an email program or any other software using gnupg. duplicity creates a file, encrypts it, uploads it. duplicity retrieves an encrypted file, decrypts it, restores/verifies data.

> I should probably reformulate my questions:
>
> - Did you or someone else in the team come across a scenario, in which it is useful to not having
>   to expose the private encryption key for backups with duplicity?

the whole private key issue derives from a misunderstanding anyway. users are rightly reluctant to put their private key on some machine connected to the internet. but they _do not_ need to! the proper approach is to encrypt against several public keys: one being unique to the local machine, another being your own public key. this way only the local private key is needed for decryption as it is need for signing anyway. if the local key get's lost for some reason you can still decrypt using your own private key on another machine as a last resort.
this whole idea can be extended by as many keys you want to encrypt against. in case you are in the habit of loosing them weekly or whatever ;)


>   This is what I meant when I wrote at the beginning, that I might be missing something obvious:
>   I agree with you, that if the system is compromised, the backup is likely to be a lost cause too.

not only likely - definitely is, at least is to be treated as such. the attacker can modify your data which will be backed up by the usual duplicity backup routine. so the backup will look good, but the data still isn't proper anymore.

>   Therefore, even with all my pondering summarized above, I still struggle to understand, why
>   someone would want to go down that rabbit hole.

which rabbit hole exactly?

> - Also related to https://lists.launchpad.net/duplicity-team/msg02374.html and the remark

yeah, also me advocating the multiple key approach :)

>   regarding verifying the backups, what is your or the teams opinion regarding the usage of
>   Amazon Glacier, especially because version 0.8 seems to support it out of the box?

none specific wrt. me. to each their own.

>   I am aware, that periodical verification of backups is not limited to duplicity as well, the reason
>   for this question is, that I am struggling to reconcile this requirement, the statements in
>   the linked post and the flag "--s3-use-glacier".

if you want to or can afford S3 that is your decision. the fact that the service charges per traffic volume does not make it attractive from my point of view, but who am i to tell people which backend to use.

> - Finally, if you had the time and leisure to read through my admittedly somewhat circuitous
>   insights outlined above, I would be grateful if you let me know, if you think that additional

yeah, well, no sorry. if you could boil it down to some short concise questions maybe.

>   aspects are incomplete or incorrect, besides the fact, that the destination would have to be
>   "append only" and that it is likely unavailing in any case.
well. append only can also mean that on the repo side, daily snapshot are done so that you can verify that your past chain's files were not modified after being created. or daily checksums are taken. it's up to your creativity really.

the primary target of duplicity is "backup to a potentially untrusted backend" meaning you assume that someone might have access to it. that's why you should
- idealy backup to several repos (using a local file:// target and distribute from there or using multi:// backend)
- verify periodically to make sure your backups are uncorrupted

stay healthy ..ede/duply.net