[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implement
From: |
Colin Walters |
Subject: |
Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes |
Date: |
Sun, 01 Feb 2004 14:52:34 -0500 |
On Sun, 2004-02-01 at 13:29, Sylvain Defresne wrote:
> I'm new to tla and to this list, so I may have mis-understood
> something. But how does this server-side delta computation interact with
> signed archive ? I was under the impression that each changeset is
> signed independently, and I don't see how the delta can be signed since
> the server. Or does this only work for non-signed archives ?
That's a very good question. The overall answer is that I haven't
considered signing too much. But I see two approaches:
1) The summary delta could be merely a concatenation of changesets, but
gzipped together - which would still give you a space savings. That way
a client, if it wants, can verify the individual changesets. Admittedly
this option isn't a big win, since it's probably the individual
changeset application that will be expensive.
2) Having a "server key" which is used to sign the deltas.
In practice though, I think what the signatures are really useful for is
verifying an entire archive after a system compromise. Just securing
the download against MITM attacks could also be done with strong
authentication; for example, https or ssh. If you have that, then you
could presume the server hasn't been compromised, and just not verify
signatures.
signature.asc
Description: This is a digitally signed message part