Re: [Duplicity-talk] Asymmetric backups broken in 0.6.15?

[edgar . soldin]

On 07.09.2011 20:24, Georg Lutz wrote:
> On 2011-09-04 12:06, address@hidden wrote:
>> Dan,
>>
>> also read the answer to you bug comment
>> https://bugs.launchpad.net/duplicity/+bug/793096/comments/11
>>
> 
> Hi Edgar,

hi George,

> 
> as it seems there has already been an emotional discussion on that
> topic. Therefore please don't get me wrong, I am just trying to
> understand things.

no problem, was more a matter of attitude, already resolved by now

> 
> That said I must admit that I too like the possibility for incremental
> backups not to have to provide the secret key as I use my regular gpg
> key for backup encryption (for backup signature I use a seperate sign
> key). :-)

agreed, i'd like that too

> Also I see it as advantage when the backed up machine does not have to
> know the secret key itself e.g. when I run duplicity on multiple
> customers machines with my own public key and don't want one customer to
> be able to decrypt other customers backup.

that's the point to want that right

> Of course decryption of backup must be done locally then. But this
> happens rarely enough. :)
> 
> What I don't fully understand is why duplicity must have access to the
> private key during incremental backups when a local archive with
> metadata is already available. Could you explain it please?

to check that the meta data is up to date. it could be incomplete, corrupted 
and that could lead duplicity to create an incremental that when restored 
contains corrupt data. but that's a could, not a must, and assumes that 
something fishy happened to your archive dir.

it's about security to compare local with remote state before continuing a 
backup chain.

> I think one of the first bug reports was this one:
> 
>  https://bugs.launchpad.net/duplicity/+bug/435975
> 
> Apparently there has already been intentionally a support for "backup
> without private key" in the past. So why exactly this support has been
> dropped?

it has not. it simply does it the same insecure way as in 0.5 and that only on 
english locale machines because the error on comparing archive dir to remote 
metadata is ignored.

> 
> Currently I run 0.6.13 sucessfully with the LANG="" workaround. But if I
> get it right this workaround caused duplicity to just correctly
> identifiy the "No secret key" and return "none" instead of raising an
> exception. And now (>=0.6.14) "none" leads to an error in the calling
> code. Is this correct?

i am not aware that tis was fixed in 0.6.14 or 0.6.15 .. it should still work 
as you describe it

> OK, as you write in
> https://bugs.launchpad.net/duplicity/+bug/793096/comments/8 you consider
> the current possibility to do backups without a secret key as a bug.

because the user assumes that the backup process is safe, but actually it is 
not, because the comparision does not happen. my rationale is, if a user should 
take that risk, he should be aware.

> 
> In the referenced bug #687295 the long term solution would be a hashing
> comparison. Is there really a need to check the remote archive directory
> against the remote one?

you mean compare local vs remote. and yes, i described it above. 

regards ede/duply.net