[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: Tue, 07 Dec 2010 16:38:58 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20101027 Thunderbird/3.1.6

We only ignore the 'no secret key' error, everything else raises an
exception.  Yes, this is potentially prone to errors, but its acceptable in
a Catch-22 situation such as this until we can find another way to verify
contents without decrypting.

Sorry to disagree, but the absolut minimum would be to print a notice that the 
comparision did not happen.
In the current state users could overwrite their more recent repository with duplicity 
telling them that their local cache was up to date. I even suggest to have users to 
enable this "feature" knowingly by a specific parameter e.g. '--no-secret-key'. 
This way we can document what's up and users can decide with knowledge of the matter.

I don't see the invasion adding just one file which holds lines with each
file and the local plus remote checksum. Rationale is, that the remote
checksum cannot be in the remote manifest, as the encryption happens after
the creation of the manifest.

It's invasive in that it touches a lot of duplicity code and has backwards
compatibility issues.  The hash could be put at the bottom of the manifest
file, and with a bit of trickery, be made to be a hash neutral line.  I
don't remember how to do that at the moment, but it's possible.

I see where you are going .. hash neutral line is a nice construct, in any 
aspect ;)

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

Of course.
But, due to the bug described above, people on 'en_US' locale might come to
the conclusion, that they don't need a private key anymore, because the
decryption error is silently ignored.

Yes, this needs to be fixed.  Has a bug report been filed yet?

Will have a look and add it if not. For the sake of efficience I'll link to the 
mailing list thread there.

What are your plans until hashing is in place?
What do you think about a more user informed exception (adding a parameter 





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


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


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


After further investigating. This seems to be a bug in

collections.py:get_remote_manifest() ca. line 211.


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

--status-fd output

- Three, falling back to local manifest in check_manifests() when

get_remote_manifest() returns None. Shouldn't the remote be authoritative

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?


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


the remote manifest might be the way to go on this.


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
memory fails here.

Unless this comparison is dealt differently (maybe in a future


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


need for the private key.


On Tue, Nov 23, 2010 at 6:49 AM,<address@hidden>     wrote:

   In theory duplicity does not need the private key of a backups


public key for incremental backup anymore. This is possible due to


unencrypted contents of the archive dir.

In practice a duply user now stumbled over the following. I can



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

"The matching private key is missing"

What is going on here. Can somebody more familiar with the
please confirm this behaviour. I tried version 0.6.06, 0.6.08 and


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


--verbosity '4' --exclude-globbing-filelist '/srv/www/vhosts/
jamoke.net/.duply/keytest/exclude' '~/duply_dev'


thanks ede/duply.net

Duplicity-talk mailing list

Duplicity-talk mailing list

Duplicity-talk mailing list

Duplicity-talk mailing list

reply via email to

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