Re: [Duplicity-talk] duply: Allow to disable gpg key export

[edgar . soldin]

On 18.07.2017 12:22, Lukas Czerner wrote:
> On Tue, Jul 18, 2017 at 11:52:07AM +0200, address@hidden wrote:
>> On 17.07.2017 17:25, Lukas Czerner wrote:
>>> Hi,
>>>
>>> I am a new user of the duply script and I quite like it, however before
>>> I can seriously use this I have to disable the key export. I do not want
>>> my keys to be scattered all over the place, I need to keep them in one
>>> location only. I hope you choose to apply this.
>>>
>>
>> well, security-wise this makes no sense, as an attacker who has access to 
>> your box may access both locations. convenience-wise it is practical as you 
>> only need to keep your profile folder safe and it will contain all the keys 
>> you need to restore your data to another box.
> 
> Hi,

Lukas,
 
i'll forward this to the duplicity ml too, just in case somebody wants to chime 
in over there.

> security wise it does make a lot of sense. You need to know where your
> keys are stored in order to make sure it's not accidentally exposed.
> This is very hard to do in situation where your application (and
> possibly others) copy your keys around.
> 
> Now practically, I am using different backup and sync solutions and I want
> to make sure my keys are not included in any of those unless I
> specifically choose to. Your approach makes it more inconveniet to me,

your duply profiles probably contain sensitive data (backend credentials, key 
passphrase) anyway. where are the profiles located in your system? if they are 
in the standard locations (/etc/duply, ~/.duply) i don't see the advantage of 
the switch, as the keys are instrumental to restoring, but may get lost if they 
were not explicitly bundled with the profile.

> so I disabled it on my system and I think others might benefit from this

there is the chance one deactivated it and forgot about it and will be unable 
to restore because of missing keys.

btw. if you are using your personal secret key to sign and decrypt the backup, 
that's bad practice. consider using a passphraseless machine key pair for 
en/decryption and additionally add your personal public key as key to encrypt 
against.
that way only the machine key pair and your personal _public_ key will end up 
in the profile.

> as well. But ultimatelly this is your call.

understood, just hesitant, that's all.

> 
> Thanks!

no problemo.. ede/duply.net