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

[Kenneth Loafman]

There are a couple of solutions to this that come to mind:

1) Get the translations for the GPG error messages, not from the translators, but from running GPG itself.  I don't know if that would be maintainable, but it's the best solution, unless we can convince them to output error codes corresponding to each of the error types.

2) When storing the manifest, hash both the encrypted form of the manifest and the unencrypted form and store the hashes somewhere (yet another file).  When comparing the manifests, get the hash pair from the file and rehash the files.  The hash of each should be equal to the stored hash in the file.  Lots of downside on this due to adding another file to the collection set.  It might be sufficient to just store the remote hash in the manifest itself.  That would be less invasive.

Short term, put the private key back into the keyring and make sure only root can read it.

...Ken

On Sat, Dec 4, 2010 at 7:56 AM, <address@hidden> wrote:

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
>>>>>



_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk