[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: Greg Stein <gstein_at_lyra.org>
Date: 2003-12-11 10:56:37 CET

On Wed, Dec 10, 2003 at 12:40:45PM -0500, Philippe Lavoie wrote:
> I was re-reading an old article
> (http://news.com.com/2100-7344-5117271.html?tag=nefd_hed)
>
> And here is an interesting tidbit of information.
>
>
> We expect to take measures in the aftermath of the Savannah incident,"
> said Eben Moglen, general counsel for the Free Software Foundation,
> which maintains the GNU Project, a source of freely available software
> for Unix and Linux systems. Among the measures, the project leaders will
> force developers to digitally sign any code they submit, and they plan
> to introduce additional features to freely available source-code
> maintenance systems--the best known being the Concurrent Versions
> System, or CVS--to check developers' digital signatures before accepting
> changes

Note that it seems possible to read this as "digital signatures are
present while accessing the repository". I don't think it is necessarily
that a signature is stored as part of the metadata of a particular
changeset.

> Has Subversion taken steps to add some kind of digital signature to
> commits? Is this necessary at all?

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.

As mentioned before, OpenCM would be the system to use if there was a
concern about needing to provide non-repudiation of the contents of the
repository. It prevents hackers and sysadmins from tweaking the repository
in an undetectable fashion. Yes, they *can* do it, but not in a way that
still passes all the crypto validation in OpenCM.

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 :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 11:00:22 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.