duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] Manifest stores SHA1 hash of files, checked before


From: edgar . soldin
Subject: Re: [Duplicity-talk] Manifest stores SHA1 hash of files, checked before restore?
Date: Mon, 18 Jul 2011 16:58:45 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0

On 18.07.2011 16:42, Chris Poole wrote:
> On Thu, Jul 14, 2011 at 6:16 PM,  <address@hidden> wrote:
>> On 14.07.2011 18:57, Chris Poole wrote:
>>> But when I backup incrementally, why is it wanting my passphrase for
>>> encryption? It doesn't need to to encrypt to my public key, so it
>>> should only require it for signing.
>>
>> it needs to decrypt the remote manifest. please read the mailing list 
>> discussion linked in http://bugs.launchpad.net/duplicity/+bug/687295
> 
> [snip]
> 
>>> Local and remote caches were synced, so it didn't have to pull
>>> manifest and signature files from the remote and decrypt them before
>>> starting the backup.
>>
>> as above. as far as i recall the sync is determined by information which is 
>> in encrypted remote manifest.
> 
> But if I don't supply a signing key and just an encryption key, this doesn't
> happen. If the local and remote are synchronised already, why is it asked for?


to determine if they are synchronized already. the local archive cache is 
unencrypted manifests of the remote location. but i am not sure if this is what 
you asked. what is this in 'this doesn't happen'.


> (Using just encryption and no signing would still produce a reote manifest 
> file
> that would need to be decrypted, asking a passphrase, but Duplicity can tell 
> if
> the file is already in the local cache.)

duplicity is not simply comparing local/file vs. remote/file.gpg.. it uses the 
manifest files, again a hash based comparision is needed/planned but not yet 
done

> 
>>> When I perform a full backup, I'm only asked for my passphrase twice.
>>> Still too much, I think, since gpg would throw an error if the
>>> passphrase didn't allow the first signing to take place, so the
>>> replication on the user's part shouldn't be required.
>>
>> that's what i argued. but the opposite also has a point that this way you 
>> don't have to restart duplicity. see ken's answer 2/3 posts ago.
> 
> I understand that, but it's less work for the user to just type it once
> correctly, isn't it? Perhaps worth filing an enhancement bug, or not?
> 
> It's annoying because my passphrase is pretty long, so it's a pain typing it 3
> times.

please do, also i proposed a patch which introduces a --encrypt-sign-key switch 
and reuses the passphrase if sign key is also one of the encryption keys
see http://bazaar.launchpad.net/~ed.so/duplicity/encr-sign-key2/revision/762

> 
> (On a side note, I can use gpg-agent and use --use-agent with duplicity, which
> works, but I still get asked for the passphrase (by pinentry) more than once 
> for
> some reason. The second time, a load of Duplicity's text starts filling the
> pinentry screen, making me unsure if the entry is actually secure or not. It
> works fine just using the gpg binary directly to sign some files.)
> 
> 

please post an private data obfuscated shell output showing gpg-agent and 
duplicity -v9 call.


ede/duply.net



reply via email to

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