[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Plans to add signing ?

From: Tom Lord <lord_at_emf.net>
Date: 2003-12-11 20:52:53 CET

> 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

This is an archived mail posted to the Subversion Dev mailing list.