[Top][All Lists]
[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
>>>>>
- Re: [Duplicity-talk] duplicity incr - private key missing,
edgar . soldin <=