> From: solo turn <soloturn99@yahoo.com>
>> I think that in the long run the fix people are moving towards
>> will involve:
>> a) making sure (to the limits of key mgt.) that all new
>> entries to the source base come from authorized
>> contributors
>> 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."
>> To validate the project host after a known compromise, for example,
>> one would have to read every revision of every file of every project
>> -- verifying both that the signature of that revision has not changed
>> and that the file contents still match the signature. At the very
>> least, it's going to take a lot of work to optimize such a process.
>> It doesn't work just to let clients do all the verification on
>> check-out: that would mean distributing to clients _both_ all of the
>> necessary public keys _and_ a trusted historic record of what the
>> particular signature is supposed to be.
> a public key is public, and its an independent problem how you
> get public keys. maybe there are public key servers where you
> send a list of serial ids and get back a list of keys?
Well, again, because of the issues that support (b), just a filled
key-ring really isn't enough.
> and you can choose what to check. you are fine if you check the
> things you need (i.e. check out).
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.
> if you sign developpers work, how much would you gain, if you
> just sign change sets? or what entity would you like to sign to
> make it secure?
I'm not quite sure I understand your question.
When you talk about "just signing changeset" -- well, that makes
pretty good sense for arch since the archives contain the changesets
(computed and signable client-side) as discrete files that are never
modified. So a project host can periodically or in an emergency just
scan all of those files and double check their signatures -- much like
they would verify an FTP site.
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.
-t
---------------------------------------------------------------------
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:32:06 2003