#50 Feature: Disable GPG key backups

[Matthijs Kooijman]

Currently, duply automatically backups GPG keys to the profile directories. I would like an option to disable that behaviour.

The reason I do not want these backups is:

• I have a private key locally generated on my backed-up-machine, living in the root gpg keyring. I do not want this key to leave that machine at all, so my backups are additionally encrypted to my personal GPG key, which removes the need for preserving the original private key (which is only used when restoring and verifying from the machine itself).
• I do want to backup the duply profile directories, to make it easy to restore files from another machine. I just want to be able to scp/rsync /etc/duply to my other machine, but now I have to carefully exclude the keys to prevent them from leaving the backed-up machine.
• I am considering to protect the original private key with a passphrase, manually loading it into an agent when the backed-up machine for use by duplicity. This ensures that physical access to the machine does not so easily leak the backup private key (disk theft or a forced reboot does not expose the clear-text key). This scheme is completely voided by storing passphrase-less keys in /etc/duply.

Thinking about this, I guess it would only be needed to disable backup of the private key, the public key is not sensitive and would actually be convenient to sync to my other machines.

Would something like a GPG_DISABLE_PRIVATE_KEY_BACKUP option (maybe something shorter?) make sense?

[Matthijs Kooijman]

As a workaround, I've now made the private key backup files empty. This prevents new backups from being made, without leaking the keys. This is somewhat fragile, though, since if I make a new profile and forget to empty the files, I'll be leaking the key anyway...

[ede]

while it's easily implementable by yet another config var i am a bit hesitant (again sorry;9).

reason is, that your profile is meant to be the private data/config to restore your data e.g. on a new machine. it is supposed to contain all the "secrets" needed (backend credentials, keys) so that the user does not have to worry about them.

encrypting against a second (like your personal) public key is suggested anyway, even if only to recover your backup in case the machine key is lost/corrupted somehow.

generally your duply profiles need to be secured locally anyway (file permissions etc.) so only the user doing the backups can read them. so if you copy it over to another machine it is your job to do it in a secure manner. if youdon't want the private keys to leave the local machine simply don't copy them ;) e.g. via rsync --exclude="**/*.sec.gpg"

as a workaround, if you are insistant you may of course hack it ;). you should be able to add the keys in question to DUPL_PARAMS conf var as described in the duplicity man page and duply should ignore them. not sure if the gpg test will succeed then though!

..ede/duply.net

[Matthijs Kooijman]

Hm, I settled for the workaround of excluding the files in a sync (I'm not too happy about it, since it's still to easy to accidentally leak the keys), but ran into the same problem in a different way.

I'm making backups of my server and just synced the duply configs to my local laptop. Backups are encrypted to one private key that lives on my server and my personal private key that lives on my laptop.

Now, when I run any duply command (I think, I tried status), it will try to export my personal private key. Of course it has a passphrase, so I get a prompt that I can cancel, but that seems to fail the backup. Even if it wouldn't, I really do not want my personal private key end up on any disk without a passphrase, so I would rather have duply not try this at all.

Implementing a GPG_DISABLE_PRIVATE_KEY_BACKUP would fix both problems for me. Since you would typically sync the config between backup and restore host, this would disable key backups for both and I can imagine that others might want to backup their backup key but not their personal key, which would need something like selecting specific keys to be excluded (or included) in the backup. Or, you could imagine that anyone that encrypts to multiple keys is going to do their own private key management anyway and does not backups at al (so a blanket GPG_DISABLE_PRIVATE_KEY_BACKUP would be fine).

[ede]

yeah, the dual secret key approach was not within the scope of the initial duply development. to implement a black-/whitelist for keys safe to im-/export seems possible, but too elaborate just for this "feature".

right now i feel like optional GPG_IMPORT/EXPORT="disable" for cases like yours are the easiest way to go.

will give it a go, when i find the time.. ede

[ede]

added/implemented settings

# disable automatic gpg key importing altogether
#GPG_IMPORT='disabled'
# disable automatic gpg key exporting to profile folder
#GPG_EXPORT='disabled'

will be in next release duply v2.3 ..ede

[Matthijs Kooijman]

Took a while for me to test this, but I just did and it works perfectly. Thanks!

[ede]

good to hear!.. sunny regards ede