duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] duplicity incr - private key missing


From: edgar . soldin
Subject: Re: [Duplicity-talk] duplicity incr - private key missing
Date: Sat, 04 Dec 2010 14:56:47 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6

ken,

could you please comment this? We should at least fix the silent 
get_remote_manifest failure for the next release.

ede/duply.net

On 23.11.2010 19:18, address@hidden wrote:
> Boom. And here comes the fun part:
> 
> Exporting LANG=en_US.UTF8 enables incremental backups without private key.
> 
> After further investigating. This seems to be a bug in 
> collections.py:get_remote_manifest() ca. line 211.
> http://bazaar.launchpad.net/~duplicity-team/duplicity/0.6-series/annotate/head%3A/duplicity/collections.py#L211
> 
> It seems to catch "No secret key" errors, given the output language is 
> english ;) .. and returns None in such a case.
> 
> I see three bugs here.
> -One is blindly catching "no secret key errors"
> - Two is interpreting the text output and not using the locale unaffected 
> --status-fd output
> - Three, falling back to local manifest in check_manifests() when 
> get_remote_manifest() returns None. Shouldn't the remote be authoritative 
> here?
> 
> Ken would you explain how you'd suggest to implement a checksumming procedure 
> to remove necessity of private key altogether?
> 
> I could implement it and would remove "no secret key" exception. I also don't 
> see the rationale for the
> #Following by MDR.  Should catch if remote encrypted with
> # public key w/o secret key
> comment there. Why should symmetric decryption complain about missing private 
> key without a reason?
> 
> 
> ede/duply.net
> 
> On 23.11.2010 14:32, Kenneth Loafman wrote:
>> Yes, that is correct.
>>
>> A a hash of an encrypted form of the local manifest compared to a hash of
>> the remote manifest might be the way to go on this.
>>
>> ...Ken
>>
>> On Tue, Nov 23, 2010 at 7:17 AM,<address@hidden>  wrote:
>>
>>> I remember to have read that no private key is necessary anymore. So my
>>> memory fails here.
>>>
>>> Unless this comparison is dealt differently (maybe in a future duplicity?)
>>> at least one private key for a key used to encrypt has to reside on the
>>> duplicity box?
>>>
>>> .. thanks ede/duply.net
>>>
>>>
>>> On 23.11.2010 14:07, Kenneth Loafman wrote:
>>>
>>>> To guarantee that the remote and local caches are the same duplicity
>>>> compares the manifest files.  The remote manifest is encrypted, thus the
>>>> need for the private key.
>>>>
>>>> ...Ken
>>>>
>>>> On Tue, Nov 23, 2010 at 6:49 AM,<address@hidden>   wrote:
>>>>
>>>>   In theory duplicity does not need the private key of a backups encryption
>>>>> public key for incremental backup anymore. This is possible due to the
>>>>> unencrypted contents of the archive dir.
>>>>>
>>>>> In practice a duply user now stumbled over the following. I can reproduce
>>>>> this.
>>>>>
>>>>> Generate a key pair. Export it.
>>>>> Delete the private key from your keyring.
>>>>> Do an initial backup with duplicity.
>>>>> Do a second backup or force an incremental backup. This fails with an
>>>>> error
>>>>> like
>>>>>
>>>>> "The matching private key is missing"
>>>>>
>>>>> What is going on here. Can somebody more familiar with the encryption
>>>>> code
>>>>> please confirm this behaviour. I tried version 0.6.06, 0.6.08 and 0.6.11
>>>>> ..
>>>>> none works as expected.
>>>>>
>>>>> Commandline generated by duply is
>>>>>
>>>>> TMPDIR='/tmp' /srv/www/vhosts/
>>>>> jamoke.net/_apps/duplicity-0.6.06/bin/duplicity --encrypt-key DA3FEEDB
>>>>> --verbosity '4' --exclude-globbing-filelist '/srv/www/vhosts/
>>>>> jamoke.net/.duply/keytest/exclude' '~/duply_dev' 'file:///tmp/keyt3esrt'
>>>>>
>>>>> thanks ede/duply.net
>>>>>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]