Tom Lord wrote:
> > From: solo turn <soloturn99@yahoo.com>
> >> b) making sure that no old entries have been modified
> >> (even by an authorized contributor).
>
> > not sure if b) is necessary. if you do not trust people in a
> > network of trust you have a problem. in any case. there has to
> > be machanisms how to handle (rollback?) a compromised person/key
> > and the output.
>
> My thinking is that (b) is a critical part of intrusion detection.
>
> As for the "web of trust" -- yes and no. Project hosts have the
> problem that their web is large and barely controlled. So I think a
> distinct risk of project hosts is that you except creds from someone
> who later turns out to not be a good guy. Another distinct risk is
> that with such a large web, some % of members are going to have their
> private keys compromised and not realize it right away (or at all).
> Hence (b) -- not just "I got this new data from someone currently
> trusted" -- but also "That older data hasn't changed."
I agree.
<SNIP>
> It's a fine thing to _also_ enable clients to do independent
> verification of the data on the project host -- but it doesn't solve
> the problem that project hosts are trying to solve.
<SNIP>
> I'm not sure how you can get a sufficiently secure and sufficiently
> quickly verifiable signature system into svn without a lot of
> hacking. The DB mechanism kind of fights against it. It's going to
> be a hard problem.
I can think of approaches. The project host is probably creating dump
files for backup. These can have the hashes checked at writeout time.
If they validate then a hash of the dumpfile can be signed by the server
admin (presumably with a key kept securely on another system) to 'cache'
the verification of revisions up to revX.
At disaster time a dump up to revX is created, checksummed, and compared
with the signed hash. Only revisions newer than X now need verifying at
the individual file level. By allowing some of the verification work to
scheduled for checking up front that required to validate at any one
time can be kept feasible without major alterations to subversion.
Yours,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 20:48:14 2003