6

I'm setting up automated backups with duplicity, but there's something I don't get. I have imported my own public GPG key, but it seems that duplicity wants the private key as well. It was my understanding that the public key was used to encrypt the data, and the private key to decrypt it. Therefore, I see no reason why the private key would be needed here.

Please enlighten me :)

4
  • 2
    I don't know duplicity, but probably it's needed to sign the backups. What options are you using? Sep 10, 2011 at 14:26
  • 1
    If you're worried about security, why not make a second key-pair and give it that private key - as long as you remember which public key to use to get the backups again, that should work?
    – deanWombourne
    Sep 10, 2011 at 14:28
  • @Matteo: You're right, it's because it's trying to sign the data. That's too bad I can't mark your comment as accepted! deanWombourne: Yes, I guess it would work too.
    – Executifs
    Sep 10, 2011 at 14:31
  • @Executifs: well, this can be quickly fixed. :) Sep 10, 2011 at 14:37

3 Answers 3

5

I don't know duplicity, but probably it's needed to sign the backups.

2
  • Could you elaborate on why signing would be needed? Sep 10, 2011 at 15:38
  • 1
    If you mean "why would you need signing", it's to make sure that nobody modified the backup after the signature. If it's "why do you need a private key for signing", it's because you use it to encrypt the hash, so that everybody can check it (decrypting it with the public key) but nobody can recreate it after tampering the data. Sep 10, 2011 at 15:55
8

Duplicity doesn't sign the archive unless you specify --sign-key key-id option. In non-signing mode (only performing the encryption) the private key is needed only for the real decrypt/restore, and, let's say, archive read actions, which require re-syncing the archive with the local cache (=decrypting the archive).

In the past years this feature was changed heavily. But I can say we are automatizing it a lot without the need of private key. The biggest mistake we have been doing in the past was inconsistent directory specification, look:

  • the cache name for a particular target_url, like file:///usr/local/backup is a hash of that string
  • we have accidentally generated a slightly different url aiming the same target, like file:///usr/local/backup/ (with trailing slash) or file:///usr/local/./backup for the read actions (collection-status, list-current-files, etc)
  • when the url differs, the hash also differs and such cache doesn't exist (or is in an inconsistent state)
  • this action must create a new cache and therefore needs the private key in order to decrypt the archive
1
  • I'm so glad that's fixed! I think the hashing-the-wrong-url problem was really messing me up a while back when I tried this.
    – bchurchill
    Sep 14, 2016 at 11:47
1

Could be. But there you can create an extra signing key to keep the private key which encrypted the backup very safe.

The problem is described here: "duplicity incr - private key missing".

In short, if you have just the public key on the backup machine but not the private key, a second incremental backup will fail with error message like "The matching private key is missing". This is in fact a bug in Duplicity, which occurs when the system is not configured to use English language - apparently Duplicity checks for certain error messages from GPG and cannot handle translated error messages.

So a possible workaround is mentioned as well: setting environment variable LANG to en_US.UTF8. In fact setting it to an empty value works as well. So starting duplicity like this solved the problem for me under Ubuntu 16.04:

env LANG= duplicity ...

1
  • 1
    Please elaborate on what's found within the post, instead of just pasting a link to it. Aug 9, 2013 at 21:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .