| I'm confused, is 'duply' shorthand for 'duplicity'? Is duplicity somehow exporting the gpg private key to somewhere else other than where it lives normally (~/.gnupg) ?
~Mark On Jul 18, 2017, at 07:15, edgar.soldin--- via Duplicity-talk < address@hidden> wrote:
On 18.07.2017 15:58, Lukas Czerner wrote:On Tue, Jul 18, 2017 at 03:25:23PM +0200, address@hidden wrote:
Btw, you should not need to decrypt when synchronizing the archive
except for some special cases IIRC.
_wrong_ that's an outstanding bug (since 2010) in duplicity
https://bugs.launchpad.net/duplicity/+bug/687295
It very well may be, but with this simple workaround it works.
export LANG=C
be aware that this is a bug and will lead to inconsistent backups in case the remote is more recent than the local archive cache folder.if you value your data, which you probably do, as you do backups, you should refrain from using this "workaround".last I heard about it is that the maintainer is about to remove it finally in the upcoming duplicity 0.8.
I want to only have one so I minimize a chance
of losing, or exposing it. I'd argue that passphraseless key pairs are
bad practice though.
depends.. in this scenario you will have to provide the passphrase along with the secret key anyway, so it is up to you, if you generate the machine key pair, w/ or w/o passphrase.
the gist is that this keypair identifies (signs) and encrypts specific to this machine and the key is used for nothing else. an attacker already on your machine can modify your data/decrypt your backup/delete files on the backend etc. anyway.
the dual key approach is merely there to protect your private secret key, as duplicity needs a secret key for decryption sometimes.
To protect it from what ?
from attackers gaining access to it. as you said, ideally it is not physically located on the machine but on a keycard or such.
Are you telling me that duplicity can't be trusted
with my passphrase for the secret key ?
as much as gpg can be trusted w/ it, as duplcity is merely using the gpg cmd line binary.
Again, this is not about attacker getting to my machine. It's about
keeping track of my keys. Look at it this way, if every program would
export my private keys to it's own location, that would be a horrible
mess - so why should you script be an exception ?
1. because users will need those keys at some point, but tend to setup and forget
I tend to keep my keys safe myself. So I guess, too bad for me.
not at all. i might add the switch silently w/o promoting it, but i will still need some time to ponder over it. sorry.2. the profile folder is supposed to be located in a trustworthy location
There are more than two levels of trust and I value my keys more than
duply configuration.
3. because you _do not_ need a personal secret key if the double key approach is used
I do not think that's convenient nor secure enough.
So we have to agree to disagree here, but thanks for your time anyway.
nP.. different heads, different minds. in the end it is you responsible for your or your customers data, so you may treat it as you see fit!..ede/duply.net_______________________________________________Duplicity-talk mailing listaddress@hiddenhttps://lists.nongnu.org/mailman/listinfo/duplicity-talk
|