Greg Stein wrote:
>
> As Greg Hudson points out, if your access to the repository is restricted
> to (say) using just https, then you can also include the use of client
> certificates. That would be quite strong.
>
> But using a signature (client cert) while accessing the repository only
> verifies what comes in over that connection. If somebody hacks into the
> server and modifies the repository, the best you have there [in SVN] is a
> checksum. But that can easily be recomputed by the hacker. Subversion
> repositories are much harder to tweak than a CVS repository, but a
> determined hacker could compromise a repository in an invisible fashion.
<SNIP>
> I suspect that somebody could write a post-commit hook which applies an
> MD5 or SHA1 hash to each file (and/or set of properties) that gets changed
> in a commit, then send those off-system. If a system compromise ever
> occurs, then the hashes could be recomputed and compared to the off-system
> values. I think with some tricks, you might even be able to store them
> on-system in a safe fashion (e.g. such that you can add new hashes, but
> not change existing hashes). Easiest is to send off-site and hope *that*
> system doesn't get compromised too :-)
The client certs could be used to sign SHA1 hashes before submitting
data. The server could validate the hash and signature then store it as
a property.
If the server was later suspected of attack the admin could verify every
version, as long as they have a trustworthy collection of users public
certs (which could be recollected from/verified with the users if
necessary). Individual users could also verify their WCs by checking
signed hashes against the text-base, as long as they also have been
storing users public keys.
Users would have their client certs signed by the project admin as proof
of submit rights. This would allow other users to trust that their
collections of public keys are valid. As with all PKI this is
predicated on all private certs (user and server) remaining uncompromised.
This seems as if it would fit in just fine with svn's architecture, and
would make a worthy post-1.0 extension.
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 17:20:50 2003